www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - this is almost a workaround for the lack of named parameters

reply "J" <not_avail notavailable.com> writes:
#!/usr/bin/rdmd
void main(string[] arg) {

   // Observation: I'd like to say:
   /*
   auto r = myfunc.call("named") with { z= 2; x = -123; y = 200; }
   */

   // and have it turned into this:
   with(myfunc) { x = -123; y = 200; z = -20; }
   auto r = myfunc.call("named");

   // Q: is there some way to achieve this? Maybe a variation on 
with?

   // Is there a macro facility lurking someplace?  Or is there 
another way to do this?
   // Thanks!
   // - J
}

import std.stdio;

struct myfunc_
{
    // named keyword or named parameters
    // --the call arguments and their defaults
    int x=0;
    int y=0;
    int z=0;

    string call(string non_keyword_arg)
    {
      writefln("%s:  X %s, Y %s, Z %s", non_keyword_arg, x, y, z );
      return "yo";
    }
}
myfunc_ myfunc;
Mar 21 2013
next sibling parent reply "J" <not_avail notavailable.com> writes:
   // CORRECTION:
   // and have it turned into this:
   with(myfunc) { z =2; x = -123; y = 200; }
   auto r = myfunc.call("named");
Mar 21 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-03-22 11:17, J wrote:
 With credit for inspiration to David Medlock in this post--
 http://forum.dlang.org/thread/d9lnrr$26q3$1 digitaldaemon.com ...

 // Tongue firmly in cheek, I'd like to introduce
 // the NAPAPISS principle: (with apologies to SFINAE and RAII)

 // NAPAPISS = NAmed Parameters Are simply Passed in a Struct, Silly.

 // Yes, indeed, maybe this is what happens after drinking too much of
 // the fine wine products from the Napa valley... you start having
 // wild flights of fancy of how D might surprisingly soon have
 // named parameters....


 import std.stdio;
 import std.c.stdlib;

 void main(string[] arg) {

      // this works today: but with the drawback that the
      // named params must be known at compile time...

      // Here is a named param call,
      // as compact as I could get it (see struct below for actual
 definition).

      auto a = myfunc!q{ z= 2; x = -123; y = 200 }(0)(); // calls opCall
      writeln("a=", a); // prints "a=yo", as returned from opCall



      // And here's the runtime version, unfortunately you have to
      // pre-declare g because otherwise it won't survive the scope, and
      // the return value from myfunc.opCall would become inaccessible.
      string g;
      with(myfunc!()(0)) {
            x=rand() % 40;
            y=x/2;
            z=y/2;
            g = call(); // as a side effect, prints 'X 7, Y 3, Z 1'
       }
       writeln("g=", g); // prints "g=yo", as returned from opCall


 /*
      // The bright future: this demonstrates that
      // it would be fairly trivial to make some kind of annotation
      // like  kwarg or whaterver, to indicate that a function
      // was using this calling convention:
       kwarg string f(int a, string b) { body; }

      // so that  kwarg function definitions are lowered to:
      struct f_kw {
        int a;
        string b;
        string f() { body; }
      }

      // and calls to  kwarg functions are transformed
      // from this:
      auto r = f(a=5, b="good");

      // into this:
      f_kw tmp34;
      tmp34.a = 5;
      tmp34.b = "good";
      auto r = tmp34.f();

      // the benefit: named parameters can be used in a natural way,
      // and they need be known only at runtime.
 */
 }

 // how the 'works today' above examples were implemented:
 struct myfunc(string init_string="")
 {
     // named keyword or named parameters
     // --the call arguments and their defaults
     int x=0;
     int y=0;
     int z=0;

     this(int) {}
     string opCall() {
       mixin(init_string ~ ";");
       writefln("X %s, Y %s, Z %s", x, y, z );
       return "yo";
     }
     alias opCall call;
 }

Here's my proposal for anonymous structs that can be used as name parameters: http://forum.dlang.org/thread/kfbnuc$1cro$1 digitalmars.com?page=1 -- /Jacob Carlborg
Mar 22 2013
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
22-Mar-2013 23:03, deadalnix пишет:
 On Friday, 22 March 2013 at 18:48:56 UTC, timotheecour wrote:
 so i hacked up a working solution yesterday.
 advantages over
 https://github.com/jacob-carlborg/mambo/blob/master/mambo/util/Reflection.d#L135:

 no need to no arguments at CT (just names); allows optional and non
 optional ones; allows return value; also, mambo depends on tango and
 is hard to revive.

 More later.


 see:
 https://github.com/timotheecour/dtools/blob/master/dtools/util/functional.d


 nothing to install, just call:
 rdmd --main -unittest dtools/util/functional.d


 auto s=callNamed!(fun,`x,y`)(10,20);
 given a function:
 auto fun(int x,int y=2,double z=z_val, string z2="asdf");

 Compile time errors will occur on duplicate param names, or ones that
 don't exist, or ones that are not optional and not provided (eg x, above)

 Feel free to contribute / comment

Don't have time to look at the code now, but it seems awesome ! Great leverage of language capabilities. Slightly different from my proposal, but I'm really not sure which interface fit best. I'm starting to think this should be : callNamed!(fun,`x`, `y`)(10,20);

Can opDispatch & chaining be leveraged to get the effect of: named!(fun).x(10).y(20).call(); Or maybe even simpler?
 But I'm not sure of all the pro and cons.

-- Dmitry Olshansky
Mar 22 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-03-22 21:02, Dmitry Olshansky wrote:

 Can opDispatch & chaining  be leveraged to get the effect of:
 named!(fun).x(10).y(20).call();

Here you go: http://pastebin.com/ALaXLgt3 Use that together with "callNamed" from timotheecour. -- /Jacob Carlborg
Mar 23 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-03-23 16:55, John Colvin wrote:

 A simple example is matplotlib.pyplot.plot

 There are so many possible flags and parameters that can be passed in
 order to get the exact behaviour you want, but commonly you'll only want
 a few set for each call. You don't want to have to set all the other
 preceding parameters, you just want to go e.g. plot(data, linewidth=5)

I've heard it was a big boost for C# when it got support for default arguments and named parameters. It made it a lot easier to integrate with COM. -- /Jacob Carlborg
Mar 23 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-03-24 03:05, timotheecour wrote:
 I updated
 https://github.com/timotheecour/dtools/blob/master/dtools/util/functional.d
 to incorporate Jacob Carlborg's idea (thanks for the working+clean code!
 let me know if attribution is ok)

Absolutely.
 If 'fun(z:3,x:4)' syntax later comes to D, it'd be trivial to write a
 tool that automatically changes the named!fun syntax in people's /
 phobos' source code to use the new cleaner syntax.

 main benefit IMO: prevent boilerplate code like this:

 struct Options{int x; int y=1; int z=2;}
 auto fun(Options options);

 Options options;
 options.x=4;
 options.z=3;
 auto a=fun(options);
 (or similar with param expansion: auto
 a=fun(options.x,options.y,options.z))

What would be nice is to be able to do like this: struct Options{int x; int y=1; int z=2;} auto fun(Options options); fun(y: 2, z: 45, x: 4); Then add opDispatch to Options to soak up any varialble not found in Options: struct Options { int x; int y = 1; int z = 2; private Variant[string] values; void opDispatch (string name, T) (T value) { values[name] = Variant(value); } ) fun(y: 2, foo: "asd", bar: 4.0, z: 45, x: 4); x, y, z are mapped to the variables in Options. foo and bar are handled by opDispatch. See my proposal for anonymous structs: http://forum.dlang.org/thread/kfbnuc$1cro$1 digitalmars.com -- /Jacob Carlborg
Mar 24 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-03-24 09:13, Philippe Sigaud wrote:

 Also, I see that at one time, you used a full string syntax:

 auto result = nfoo(q{z = "Title", x = 1, y = 100}); // nfoo will parse
 the input string

 I rather like this one. Why did you ditch it?

That would requires compile time values, i.e. no variables. -- /Jacob Carlborg
Mar 24 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-03-24 03:05, timotheecour wrote:
 I updated
 https://github.com/timotheecour/dtools/blob/master/dtools/util/functional.d
 to incorporate Jacob Carlborg's idea (thanks for the working+clean code!
 let me know if attribution is ok)

BTW, why was the constructor added to Proxy and the "dummy" argument? -- /Jacob Carlborg
Mar 24 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-03-24 20:59, timotheecour wrote:
 BTW, why was the constructor added to Proxy and the "dummy" argument?

because I wanted to simplify syntax from 'auto ret2=named!fun.z(3).x(4).call();' to 'auto ret2=named!fun.z(3).x(4)();' In doing that, I was having CT errors without it due to ambiguity between default unnamed constructor and opCall, so I added constructor. Then inside the named() function i needed to return a proxy object. Alternatives were: return Proxy!(func, null)(); //wrong: would call opCall return Proxy!(func, null).init; //not sure if it would incur overhead return Proxy!(func, null)(0); //introduces dummy arg, which should be optimized away.

Aha, ok I see.
 Finally, how do I reply from my email client ? Right I'm using
 http://forum.dlang.org/ otherwise the message isn't delivered on the
 forum... Thanks!

I'm using Thunderbird and just using "Reply to the message". -- /Jacob Carlborg
Mar 24 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-03-24 23:53, a a wrote:

 using gmail but doesn't work... (testing again via this message...) pls
 ignore if this succeeds!

I got this. -- /Jacob Carlborg
Mar 25 2013
prev sibling next sibling parent "J" <not_avail notavailable.com> writes:
   /*  Similarly but different (here I am instantiating a new 
struct
       before the call, rather than re-using a global single 
struct each time),
       it would be lovely and elegant to say:
   */

void main(string[] arg) {

   /* Elegant:

      auto r = myfunc() with { z= 2; x = -123; y = 200; }

   */

   // and have it lowered to:
   myfunc tmp;
   with(tmp) { z= 2; x = -123; y = 200; }
   auto r = tmp();

}

import std.stdio;

struct myfunc
{
    // named keyword or named parameters
    // --the call arguments and their defaults
    int x=0;
    int y=0;
    int z=0;

   // opCall is sweet... improves upon previous example

    string opCall(string required_positional_arg = "default pos 
arg value") {
      writefln("%s:  X %s, Y %s, Z %s", required_positional_arg, 
x, y, z );
      return "yo";
    }

}
Mar 21 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-03-21 19:35, J wrote:

Here's another workaround: 
https://github.com/jacob-carlborg/mambo/blob/master/mambo/util/Reflection.d#L135

-- 
/Jacob Carlborg
Mar 21 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-03-21 21:33, bearophile wrote:

 Maybe such two links should go in one page of the D wiki about lack of
 named parameters workarounds.

 Eventually D should introduce a syntax for named arguments at the call
 point plus a syntax to deprecate argument names. It's not the most
 important thing that D currently lacks, but it's an improvement.

What do you think about my suggestion for anonymous structs as named parameters? http://forum.dlang.org/thread/kfbnuc$1cro$1 digitalmars.com?page=1 -- /Jacob Carlborg
Mar 21 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-03-21 22:18, bearophile wrote:

 You show code like:

 void foo ({ int x, int y } point)
 {
 }

 foo({ y: 5, x: 3 });


 D already has two kinds of tuples so I don't want a "third kind" of
 tuple. What I want is D to manage better the Phobos Tuple we already
 have, adding an unpacking syntax
 (http://forum.dlang.org/thread/gridjorxqlpoytuxwpsg forum.dlang.org ).
 (This is not supposed to solve the named arguments problem).

This is not a tuple, it's an anonymous struct. -- /Jacob Carlborg
Mar 22 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-03-21 21:42, J wrote:

 Intriguing, Jacob!  I could learn alot about reflection by studying your
 code.

 How is it installed?  I installing by downloading that single file, and
 with a quick hack to the Reflection.d top three lines (commenting out
 the module and imports at the top), I tried calling it with this, no luck:

 #!/usr/bin/rdmd

 import Reflection; // with module and imports commented out...
 import std.stdio;

 string my(int a, int b) {
    writeln(a/b);
    return "howdy";
 }

 void main(string[] arg) {

     auto s = callWithNamedArguments(my, `a=3, b=4`);
 }

 // yields:

 $ ./ref.d
 ./ref.d(13): Error: function ref.my (int a, int b) is not callable using
 argument types ()
 ./ref.d(13): Error: expected 2 function arguments, not 0

It's been quite a while since I tested that code. I'll see what I can do. -- /Jacob Carlborg
Mar 21 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Jacob Carlborg:

 Here's another workaround: 
 https://github.com/jacob-carlborg/mambo/blob/master/mambo/util/Reflection.d#L135

Maybe such two links should go in one page of the D wiki about lack of named parameters workarounds. Eventually D should introduce a syntax for named arguments at the call point plus a syntax to deprecate argument names. It's not the most important thing that D currently lacks, but it's an improvement. Bye, bearophile
Mar 21 2013
prev sibling next sibling parent "J" <not_avail notavailable.com> writes:
On Thursday, 21 March 2013 at 19:59:01 UTC, Jacob Carlborg wrote:
 On 2013-03-21 19:35, J wrote:

 Here's another workaround: 
 https://github.com/jacob-carlborg/mambo/blob/master/mambo/util/Reflection.d#L135

Intriguing, Jacob! I could learn alot about reflection by studying your code. How is it installed? I installing by downloading that single file, and with a quick hack to the Reflection.d top three lines (commenting out the module and imports at the top), I tried calling it with this, no luck: #!/usr/bin/rdmd import Reflection; // with module and imports commented out... import std.stdio; string my(int a, int b) { writeln(a/b); return "howdy"; } void main(string[] arg) { auto s = callWithNamedArguments(my, `a=3, b=4`); } // yields: $ ./ref.d ./ref.d(13): Error: function ref.my (int a, int b) is not callable using argument types () ./ref.d(13): Error: expected 2 function arguments, not 0
Mar 21 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Jacob Carlborg:

 What do you think about my suggestion for anonymous structs as 
 named parameters?

You show code like: void foo ({ int x, int y } point) { } foo({ y: 5, x: 3 }); D already has two kinds of tuples so I don't want a "third kind" of tuple. What I want is D to manage better the Phobos Tuple we already have, adding an unpacking syntax (http://forum.dlang.org/thread/gridjorxqlpoytuxwpsg forum.dlang.org ). (This is not supposed to solve the named arguments problem). Bye, bearophile
Mar 21 2013
prev sibling next sibling parent "J" <not_avail notavailable.com> writes:
The bigger point here is more profound: it is trivial to 
implement named parameters using structs + trivial lowerings, and 
this is no way conflicts with function overloading.

D deserves to have named parameters to functions -- it makes for 
much more legible code, and obviates the need for slow builder 
patterns.  Readable and speedable. It's win-win.
Mar 22 2013
prev sibling next sibling parent "J" <not_avail notavailable.com> writes:
With credit for inspiration to David Medlock in this post-- 
http://forum.dlang.org/thread/d9lnrr$26q3$1 digitaldaemon.com ...

// Tongue firmly in cheek, I'd like to introduce
// the NAPAPISS principle: (with apologies to SFINAE and RAII)

// NAPAPISS = NAmed Parameters Are simply Passed in a Struct, 
Silly.

// Yes, indeed, maybe this is what happens after drinking too 
much of
// the fine wine products from the Napa valley... you start having
// wild flights of fancy of how D might surprisingly soon have
// named parameters....


import std.stdio;
import std.c.stdlib;

void main(string[] arg) {

     // this works today: but with the drawback that the
     // named params must be known at compile time...

     // Here is a named param call,
     // as compact as I could get it (see struct below for actual 
definition).

     auto a = myfunc!q{ z= 2; x = -123; y = 200 }(0)(); // calls 
opCall
     writeln("a=", a); // prints "a=yo", as returned from opCall



     // And here's the runtime version, unfortunately you have to
     // pre-declare g because otherwise it won't survive the 
scope, and
     // the return value from myfunc.opCall would become 
inaccessible.
     string g;
     with(myfunc!()(0)) {
           x=rand() % 40;
           y=x/2;
           z=y/2;
           g = call(); // as a side effect, prints 'X 7, Y 3, Z 1'
      }
      writeln("g=", g); // prints "g=yo", as returned from opCall


/*
     // The bright future: this demonstrates that
     // it would be fairly trivial to make some kind of annotation
     // like  kwarg or whaterver, to indicate that a function
     // was using this calling convention:
      kwarg string f(int a, string b) { body; }

     // so that  kwarg function definitions are lowered to:
     struct f_kw {
       int a;
       string b;
       string f() { body; }
     }

     // and calls to  kwarg functions are transformed
     // from this:
     auto r = f(a=5, b="good");

     // into this:
     f_kw tmp34;
     tmp34.a = 5;
     tmp34.b = "good";
     auto r = tmp34.f();

     // the benefit: named parameters can be used in a natural way,
     // and they need be known only at runtime.
*/
}

// how the 'works today' above examples were implemented:
struct myfunc(string init_string="")
{
    // named keyword or named parameters
    // --the call arguments and their defaults
    int x=0;
    int y=0;
    int z=0;

    this(int) {}
    string opCall() {
      mixin(init_string ~ ";");
      writefln("X %s, Y %s, Z %s", x, y, z );
      return "yo";
    }
    alias opCall call;
}


On Friday, 22 March 2013 at 09:18:33 UTC, J wrote:
 The bigger point here is more profound: it is trivial to 
 implement named parameters using structs + trivial lowerings, 
 and this is no way conflicts with function overloading.

 D deserves to have named parameters to functions -- it makes 
 for much more legible code, and obviates the need for slow 
 builder patterns.  Readable and speedable. It's win-win.

Mar 22 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 22 March 2013 at 09:18:33 UTC, J wrote:
 The bigger point here is more profound: it is trivial to 
 implement named parameters using structs + trivial lowerings, 
 and this is no way conflicts with function overloading.

 D deserves to have named parameters to functions -- it makes 
 for much more legible code, and obviates the need for slow 
 builder patterns.  Readable and speedable. It's win-win.

Question for specialists of the topic : are parameter name available using compile time reflection ? Because if they are, the problem boils down to perfect forwarding issue. And it seems solvable : NamedCall!( function, "foo", fooVal, "bar", barVal); // Booya !
Mar 22 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
http://dlang.org/phobos/std_traits.html#.ParameterIdentifierTuple
Mar 22 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 22 March 2013 at 15:50:38 UTC, Dicebot wrote:
 http://dlang.org/phobos/std_traits.html#.ParameterIdentifierTuple

Seems to me like a solved problem.
Mar 22 2013
prev sibling next sibling parent "timotheecour" <timothee.cour2 gmail.com> writes:
so i hacked up a working solution yesterday.
advantages over 
https://github.com/jacob-carlborg/mambo/blob/master/mambo/util/Reflection.d#L135:
no need to no arguments at CT (just names); allows optional and 
non optional ones; allows return value; also, mambo depends on 
tango and is hard to revive.

More later.


see:
https://github.com/timotheecour/dtools/blob/master/dtools/util/functional.d

nothing to install, just call:
rdmd --main -unittest dtools/util/functional.d


auto s=callNamed!(fun,`x,y`)(10,20);
given a function:
auto fun(int x,int y=2,double z=z_val, string z2="asdf");

Compile time errors will occur on duplicate param names, or ones 
that don't exist, or ones that are not optional and not provided 
(eg x, above)

Feel free to contribute / comment
Mar 22 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 22 March 2013 at 18:48:56 UTC, timotheecour wrote:
 so i hacked up a working solution yesterday.
 advantages over 
 https://github.com/jacob-carlborg/mambo/blob/master/mambo/util/Reflection.d#L135:
 no need to no arguments at CT (just names); allows optional and 
 non optional ones; allows return value; also, mambo depends on 
 tango and is hard to revive.

 More later.


 see:
 https://github.com/timotheecour/dtools/blob/master/dtools/util/functional.d

 nothing to install, just call:
 rdmd --main -unittest dtools/util/functional.d


 auto s=callNamed!(fun,`x,y`)(10,20);
 given a function:
 auto fun(int x,int y=2,double z=z_val, string z2="asdf");

 Compile time errors will occur on duplicate param names, or 
 ones that don't exist, or ones that are not optional and not 
 provided (eg x, above)

 Feel free to contribute / comment

Don't have time to look at the code now, but it seems awesome ! Great leverage of language capabilities. Slightly different from my proposal, but I'm really not sure which interface fit best. I'm starting to think this should be : callNamed!(fun,`x`, `y`)(10,20); But I'm not sure of all the pro and cons.
Mar 22 2013
prev sibling next sibling parent "foobar" <foo bar.com> writes:
On Friday, 22 March 2013 at 10:17:02 UTC, J wrote:
 With credit for inspiration to David Medlock in this post-- 
 http://forum.dlang.org/thread/d9lnrr$26q3$1 digitaldaemon.com 
 ...

 // Tongue firmly in cheek, I'd like to introduce
 // the NAPAPISS principle: (with apologies to SFINAE and RAII)

 // NAPAPISS = NAmed Parameters Are simply Passed in a Struct, 
 Silly.

 // Yes, indeed, maybe this is what happens after drinking too 
 much of
 // the fine wine products from the Napa valley... you start 
 having
 // wild flights of fancy of how D might surprisingly soon have
 // named parameters....


 import std.stdio;
 import std.c.stdlib;

 void main(string[] arg) {

     // this works today: but with the drawback that the
     // named params must be known at compile time...

     // Here is a named param call,
     // as compact as I could get it (see struct below for 
 actual definition).

     auto a = myfunc!q{ z= 2; x = -123; y = 200 }(0)(); // calls 
 opCall
     writeln("a=", a); // prints "a=yo", as returned from opCall



     // And here's the runtime version, unfortunately you have to
     // pre-declare g because otherwise it won't survive the 
 scope, and
     // the return value from myfunc.opCall would become 
 inaccessible.
     string g;
     with(myfunc!()(0)) {
           x=rand() % 40;
           y=x/2;
           z=y/2;
           g = call(); // as a side effect, prints 'X 7, Y 3, Z 
 1'
      }
      writeln("g=", g); // prints "g=yo", as returned from opCall


 /*
     // The bright future: this demonstrates that
     // it would be fairly trivial to make some kind of 
 annotation
     // like  kwarg or whaterver, to indicate that a function
     // was using this calling convention:
      kwarg string f(int a, string b) { body; }

     // so that  kwarg function definitions are lowered to:
     struct f_kw {
       int a;
       string b;
       string f() { body; }
     }

     // and calls to  kwarg functions are transformed
     // from this:
     auto r = f(a=5, b="good");

     // into this:
     f_kw tmp34;
     tmp34.a = 5;
     tmp34.b = "good";
     auto r = tmp34.f();

     // the benefit: named parameters can be used in a natural 
 way,
     // and they need be known only at runtime.
 */
 }

 // how the 'works today' above examples were implemented:
 struct myfunc(string init_string="")
 {
    // named keyword or named parameters
    // --the call arguments and their defaults
    int x=0;
    int y=0;
    int z=0;

    this(int) {}
    string opCall() {
      mixin(init_string ~ ";");
      writefln("X %s, Y %s, Z %s", x, y, z );
      return "yo";
    }
    alias opCall call;
 }


 On Friday, 22 March 2013 at 09:18:33 UTC, J wrote:
 The bigger point here is more profound: it is trivial to 
 implement named parameters using structs + trivial lowerings, 
 and this is no way conflicts with function overloading.

 D deserves to have named parameters to functions -- it makes 
 for much more legible code, and obviates the need for slow 
 builder patterns.  Readable and speedable. It's win-win.


WTF? What do kwargs have to do with programming? Sounds more like a half-Klingon & half-Ferengi species to me.
Mar 22 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Friday, 22 March 2013 at 20:04:14 UTC, foobar wrote:
 On Friday, 22 March 2013 at 10:17:02 UTC, J wrote:
 With credit for inspiration to David Medlock in this post-- 
 http://forum.dlang.org/thread/d9lnrr$26q3$1 digitaldaemon.com 
 ...

 // Tongue firmly in cheek, I'd like to introduce
 // the NAPAPISS principle: (with apologies to SFINAE and RAII)

 // NAPAPISS = NAmed Parameters Are simply Passed in a Struct, 
 Silly.

 // Yes, indeed, maybe this is what happens after drinking too 
 much of
 // the fine wine products from the Napa valley... you start 
 having
 // wild flights of fancy of how D might surprisingly soon have
 // named parameters....


 import std.stdio;
 import std.c.stdlib;

 void main(string[] arg) {

    // this works today: but with the drawback that the
    // named params must be known at compile time...

    // Here is a named param call,
    // as compact as I could get it (see struct below for 
 actual definition).

    auto a = myfunc!q{ z= 2; x = -123; y = 200 }(0)(); // calls 
 opCall
    writeln("a=", a); // prints "a=yo", as returned from opCall



    // And here's the runtime version, unfortunately you have to
    // pre-declare g because otherwise it won't survive the 
 scope, and
    // the return value from myfunc.opCall would become 
 inaccessible.
    string g;
    with(myfunc!()(0)) {
          x=rand() % 40;
          y=x/2;
          z=y/2;
          g = call(); // as a side effect, prints 'X 7, Y 3, Z 
 1'
     }
     writeln("g=", g); // prints "g=yo", as returned from opCall


 /*
    // The bright future: this demonstrates that
    // it would be fairly trivial to make some kind of 
 annotation
    // like  kwarg or whaterver, to indicate that a function
    // was using this calling convention:
     kwarg string f(int a, string b) { body; }

    // so that  kwarg function definitions are lowered to:
    struct f_kw {
      int a;
      string b;
      string f() { body; }
    }

    // and calls to  kwarg functions are transformed
    // from this:
    auto r = f(a=5, b="good");

    // into this:
    f_kw tmp34;
    tmp34.a = 5;
    tmp34.b = "good";
    auto r = tmp34.f();

    // the benefit: named parameters can be used in a natural 
 way,
    // and they need be known only at runtime.
 */
 }

 // how the 'works today' above examples were implemented:
 struct myfunc(string init_string="")
 {
   // named keyword or named parameters
   // --the call arguments and their defaults
   int x=0;
   int y=0;
   int z=0;

   this(int) {}
   string opCall() {
     mixin(init_string ~ ";");
     writefln("X %s, Y %s, Z %s", x, y, z );
     return "yo";
   }
   alias opCall call;
 }


 On Friday, 22 March 2013 at 09:18:33 UTC, J wrote:
 The bigger point here is more profound: it is trivial to 
 implement named parameters using structs + trivial lowerings, 
 and this is no way conflicts with function overloading.

 D deserves to have named parameters to functions -- it makes 
 for much more legible code, and obviates the need for slow 
 builder patterns.  Readable and speedable. It's win-win.


WTF? What do kwargs have to do with programming? Sounds more like a half-Klingon & half-Ferengi species to me.

kwargs = keyword arguments It's a common naming convention in python, as exemplified in matplotlib.
Mar 22 2013
prev sibling next sibling parent "foobar" <foo bar.com> writes:
On Friday, 22 March 2013 at 21:10:27 UTC, John Colvin wrote:
 On Friday, 22 March 2013 at 20:04:14 UTC, foobar wrote:

 WTF? What do kwargs have to do with programming? Sounds more 
 like a half-Klingon & half-Ferengi species to me.

kwargs = keyword arguments It's a common naming convention in python, as exemplified in matplotlib.

That was meant more as a rhetorical question rather than a real one. Yes, I guessed the meaning by the surrounding context but nevertheless it was a major WAT while skimming the post. Also, Who the fuck cares whats common in Python? I was reading and replying on the *D* NG, was I not?
Mar 22 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Friday, 22 March 2013 at 21:29:46 UTC, foobar wrote:
 On Friday, 22 March 2013 at 21:10:27 UTC, John Colvin wrote:
 On Friday, 22 March 2013 at 20:04:14 UTC, foobar wrote:

 WTF? What do kwargs have to do with programming? Sounds more 
 like a half-Klingon & half-Ferengi species to me.

kwargs = keyword arguments It's a common naming convention in python, as exemplified in matplotlib.

That was meant more as a rhetorical question rather than a real one. Yes, I guessed the meaning by the surrounding context but nevertheless it was a major WAT while skimming the post. Also, Who the fuck cares whats common in Python? I was reading and replying on the *D* NG, was I not?

Kwarg seems a reasonable name, consistent with a pre-existing convention. Please suggest a better alternative if you have one. I must admit I'm bemused by your level of aggression over what appears to be a trivial matter.
Mar 22 2013
prev sibling next sibling parent "J" <not_avail notavailable.com> writes:
 auto s=callNamed!(fun,`x,y`)(10,20);


Thanks, but this is a non-solution. The name must be next to the value ( x=10, y=20), so they it will scale from 2 to 7 to 17 arguments and maintain readability.
Mar 22 2013
prev sibling next sibling parent "J" <notavail notavailable.com> writes:
On Saturday, 23 March 2013 at 05:43:22 UTC, J wrote:
 auto s=callNamed!(fun,`x,y`)(10,20);


Thanks, but this is a non-solution. The name must be next to the value ( x=10, y=20), so they it will scale from 2 to 7 to 17 arguments and maintain readability.

For a use case, compare this call reflectAndTranslate(2, 4, 5, 6, 1, 2, false, true, 15, false, true, false); Quick, without looking at the docs, what does the false after 15 do? It's very hard to tell. Compare that to: reflectAndTranslate(x=2, y=4, z=5, offset=6, alpha=1, beta=2, invert=false, twist=true, colorBrush=15, stideReduce=false, bindMatrix=true, slow=false); It's self documenting.
Mar 23 2013
prev sibling next sibling parent "foobar" <foo bar.com> writes:
On Friday, 22 March 2013 at 21:41:46 UTC, John Colvin wrote:
 On Friday, 22 March 2013 at 21:29:46 UTC, foobar wrote:
 On Friday, 22 March 2013 at 21:10:27 UTC, John Colvin wrote:
 On Friday, 22 March 2013 at 20:04:14 UTC, foobar wrote:

 WTF? What do kwargs have to do with programming? Sounds more 
 like a half-Klingon & half-Ferengi species to me.

kwargs = keyword arguments It's a common naming convention in python, as exemplified in matplotlib.

That was meant more as a rhetorical question rather than a real one. Yes, I guessed the meaning by the surrounding context but nevertheless it was a major WAT while skimming the post. Also, Who the fuck cares whats common in Python? I was reading and replying on the *D* NG, was I not?

Kwarg seems a reasonable name, consistent with a pre-existing convention. Please suggest a better alternative if you have one. I must admit I'm bemused by your level of aggression over what appears to be a trivial matter.

Your read it wrong. Not aggression but rather annoyment. Also, code readability is NOT a trivial matter and people who think that it is should have their keyboard chopped off. IMHO, I think the entire feature is a code smell and glad D does not support it. Code that needs named parameters to be more readable is poorly designed code in the first place.
Mar 23 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 23 March 2013 at 08:20:19 UTC, J wrote:
 On Saturday, 23 March 2013 at 05:43:22 UTC, J wrote:
 auto s=callNamed!(fun,`x,y`)(10,20);


Thanks, but this is a non-solution. The name must be next to the value ( x=10, y=20), so they it will scale from 2 to 7 to 17 arguments and maintain readability.

For a use case, compare this call reflectAndTranslate(2, 4, 5, 6, 1, 2, false, true, 15, false, true, false); Quick, without looking at the docs, what does the false after 15 do? It's very hard to tell. Compare that to: reflectAndTranslate(x=2, y=4, z=5, offset=6, alpha=1, beta=2, invert=false, twist=true, colorBrush=15, stideReduce=false, bindMatrix=true, slow=false); It's self documenting.

I'd argue that with or without named parameter, that code is ugly as hell. First, boolean can be replaced by enums for great benefice. Secondly, the usage of struct would also improve things quite a lot (x, y, z) is a point or a vector or something. At the end, it is about giving semantic to your code. BTW, monadic style named parameters have been proposed earlier, and I have to say this is really nice.
Mar 23 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
foobar:

 Code that needs named parameters to be more readable is poorly 
 designed code in the first place.

Have you used a language where the usage of named arguments is idiomatic, like Python, Scala or Ada? They are sometimes useful even for well designed code, like functions with two arguments. Bye, bearophile
Mar 23 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Saturday, 23 March 2013 at 15:00:13 UTC, bearophile wrote:
 foobar:

 Code that needs named parameters to be more readable is poorly 
 designed code in the first place.

Have you used a language where the usage of named arguments is idiomatic, like Python, Scala or Ada? They are sometimes useful even for well designed code, like functions with two arguments. Bye, bearophile

A simple example is matplotlib.pyplot.plot There are so many possible flags and parameters that can be passed in order to get the exact behaviour you want, but commonly you'll only want a few set for each call. You don't want to have to set all the other preceding parameters, you just want to go e.g. plot(data, linewidth=5)
Mar 23 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 23 March 2013 at 15:55:36 UTC, John Colvin wrote:
 On Saturday, 23 March 2013 at 15:00:13 UTC, bearophile wrote:
 foobar:

 Code that needs named parameters to be more readable is 
 poorly designed code in the first place.

Have you used a language where the usage of named arguments is idiomatic, like Python, Scala or Ada? They are sometimes useful even for well designed code, like functions with two arguments. Bye, bearophile

A simple example is matplotlib.pyplot.plot There are so many possible flags and parameters that can be passed in order to get the exact behaviour you want, but commonly you'll only want a few set for each call. You don't want to have to set all the other preceding parameters, you just want to go e.g. plot(data, linewidth=5)

Can't the monadic style thing do the trick ? Named!plot.linewidth(5).call(data); This is doable with actual D using compile time reflection.
Mar 23 2013
prev sibling next sibling parent "J" <notavail notavailable.com> writes:
On Saturday, 23 March 2013 at 19:56:17 UTC, deadalnix wrote:
 On Saturday, 23 March 2013 at 15:55:36 UTC, John Colvin wrote:
 On Saturday, 23 March 2013 at 15:00:13 UTC, bearophile wrote:
 foobar:

 Code that needs named parameters to be more readable is 
 poorly designed code in the first place.

Have you used a language where the usage of named arguments is idiomatic, like Python, Scala or Ada? They are sometimes useful even for well designed code, like functions with two arguments. Bye, bearophile

A simple example is matplotlib.pyplot.plot There are so many possible flags and parameters that can be passed in order to get the exact behaviour you want, but commonly you'll only want a few set for each call. You don't want to have to set all the other preceding parameters, you just want to go e.g. plot(data, linewidth=5)

Can't the monadic style thing do the trick ? Named!plot.linewidth(5).call(data); This is doable with actual D using compile time reflection.

Good point, and I'm sure we all develop our personal sense of 'code smell' based on our own past experience. I find adding lots of enums to be like doing RAII in C++: I find it a pain to have to pollute namespaces with extra enums (classes), just to get readability/safety. To me, the builder/monadic style is clunky and harder to read. I find plot(data, linewidth = 5) to be clean, clear, and more concise.
Mar 23 2013
prev sibling next sibling parent "timotheecour" <timothee.cour2 gmail.com> writes:
I updated
https://github.com/timotheecour/dtools/blob/master/dtools/util/functional.d
to incorporate Jacob Carlborg's idea (thanks for the 
working+clean code! let me know if attribution is ok)

auto a=named!fun.z(3).x(4).call();
and then simplified it a bit to:

auto a=named!fun.z(3).x(4)();

It's now looking pretty close to the ideal D syntax:
auto a=fun(z:3,x:4);

Notes:
auto a=fun(z=3,x=4);
doesn't seem like a good syntax compared to 'z:3,x:4', because 
z=3 could be ambiguous with an expression assigning 3 to z when z 
is in scope.


 I find it a pain to have to pollute namespaces with extra enums 
 (classes), just to get readability/safety.
 plot(data, linewidth = 5)
 to be clean, clear, and more concise.

I agree. In fact, I think we should push that named syntax 'named!fun.z(3).x(4)();' in std.functional once finalized, and start using it in phobos ASAP, it makes things more self documenting. If 'fun(z:3,x:4)' syntax later comes to D, it'd be trivial to write a tool that automatically changes the named!fun syntax in people's / phobos' source code to use the new cleaner syntax. main benefit IMO: prevent boilerplate code like this: struct Options{int x; int y=1; int z=2;} auto fun(Options options); Options options; options.x=4; options.z=3; auto a=fun(options); (or similar with param expansion: auto a=fun(options.x,options.y,options.z)) thanks for your comments!
Mar 23 2013
prev sibling next sibling parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
 It's now looking pretty close to the ideal D syntax:
 auto a=fun(z:3,x:4);

The last time I tried this (maybe 2 years ago, so before std.traits.ParameterNameTuple?), I used associative arrays: alias nfoo = named!foo; // nfoo is now a function admitting AA as arguments auto result = nfoo(["z":"Title"], ["x":1, "y":100]); Also, I see that at one time, you used a full string syntax: auto result = nfoo(q{z = "Title", x = 1, y = 100}); // nfoo will parse the input string I rather like this one. Why did you ditch it?
Mar 24 2013
prev sibling next sibling parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
On Sun, Mar 24, 2013 at 11:15 AM, Jacob Carlborg <doob me.com> wrote:

 auto result = nfoo(q{z = "Title", x = 1, y = 100}); // nfoo will parse
 the input string

 I rather like this one. Why did you ditch it?

That would requires compile time values, i.e. no variables.

You're right.
Mar 24 2013
prev sibling next sibling parent "timotheecour" <timothee.cour2 gmail.com> writes:
 BTW, why was the constructor added to Proxy and the "dummy" 
 argument?

because I wanted to simplify syntax from 'auto ret2=named!fun.z(3).x(4).call();' to 'auto ret2=named!fun.z(3).x(4)();' In doing that, I was having CT errors without it due to ambiguity between default unnamed constructor and opCall, so I added constructor. Then inside the named() function i needed to return a proxy object. Alternatives were: return Proxy!(func, null)(); //wrong: would call opCall return Proxy!(func, null).init; //not sure if it would incur overhead return Proxy!(func, null)(0); //introduces dummy arg, which should be optimized away. If you can find a better way (that doesn't incur runtime overhead), please do a pull request! Also, I'm wondering about: * how to put the unittest helper function "fun" inside main unittest block * whether the named!fun.z(3).x(4)(); call has any overhead over calling fun(4,2,3) directly. * how to support templated functions (here fun is not templated) * whether we should support this syntax: auto ret=named!fun.z(3)(4); //this would mean named!fun.z(3).x(4)(); ie all non-optional arguments go in the opCall(..) arguments, all optional arguments are called by name. So that would force API to freeze names only for optional arguments, not non-optional ones, cf in python: fun(4,z:3) Finally, how do I reply from my email client ? Right I'm using http://forum.dlang.org/ otherwise the message isn't delivered on the forum... Thanks!
Mar 24 2013
prev sibling next sibling parent a a <thelastmammoth gmail.com> writes:
--089e01175f7d9fee3604d8b38f2d
Content-Type: text/plain; charset=ISO-8859-1

 I'm using Thunderbird and just using "Reply to the message".

using gmail but doesn't work... (testing again via this message...) pls ignore if this succeeds! --089e01175f7d9fee3604d8b38f2d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m= argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I&#39;m using Thunderbird and just using &quot;Reply to the message&quot;.<= /blockquote><div><br></div><div>using gmail but doesn&#39;t work... (testin= g again via this message...) pls ignore if this succeeds!=A0</div></div> --089e01175f7d9fee3604d8b38f2d--
Mar 24 2013
prev sibling next sibling parent "foobar" <foo bar.com> writes:
On Saturday, 23 March 2013 at 15:00:13 UTC, bearophile wrote:
 foobar:

 Code that needs named parameters to be more readable is poorly 
 designed code in the first place.

Have you used a language where the usage of named arguments is idiomatic, like Python, Scala or Ada? They are sometimes useful even for well designed code, like functions with two arguments. Bye, bearophile

"idiomatic" is a relative term, tightly coupled to a specific language. Idiomatic D code for example is very different from idiomatic Haskell code. Idiomatic Python style in D would be very unidiomatic D code and vise versa. Each language has its own conventions, styles, set of distinct features, etc, etc and trying to use "language A" style while coding in "language B" is like trying to fit a square peg in a round hole. For instance, I would NOT use smalltalk naming conventions while writing say Java code. Both have very good and very consistent styles that are tightly coupled with their respective syntaxes and are very unsuitable to use in the other language. In short, if you want to discuss python features, style or specific math plotting libraries, please post to the python mailing list, not D's NG.
Mar 25 2013
prev sibling next sibling parent "foobar" <foo bar.com> writes:
On Saturday, 23 March 2013 at 15:59:12 UTC, Jacob Carlborg wrote:
 On 2013-03-23 16:55, John Colvin wrote:

 A simple example is matplotlib.pyplot.plot

 There are so many possible flags and parameters that can be 
 passed in
 order to get the exact behaviour you want, but commonly you'll 
 only want
 a few set for each call. You don't want to have to set all the 
 other
 preceding parameters, you just want to go e.g. plot(data, 
 linewidth=5)

I've heard it was a big boost for C# when it got support for default arguments and named parameters. It made it a lot easier to integrate with COM.

AFAIK, this is only relevant or useful for COM (i.e. to support legacy, not really OO code) and is not supported (compile error?) for regular C# code as it is *not idiomatic C#* style (and is not OO).
Mar 25 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
foobar:

 "idiomatic" is a relative term, tightly coupled to a specific 
 language. Idiomatic D code for example is very different from 
 idiomatic Haskell code.
 Idiomatic Python style in D would be very unidiomatic D code 
 and vise versa. Each language has its own conventions, styles, 
 set of distinct features, etc, etc and trying to use "language 
 A" style while coding in "language B" is like trying to fit a 
 square peg in a round hole.
 For instance, I would NOT use smalltalk naming conventions 
 while writing say Java code. Both have very good and very 
 consistent styles that are tightly coupled with their 
 respective syntaxes and are very unsuitable to use in the other 
 language.

 In short, if you want to discuss python features, style or 
 specific math plotting libraries, please post to the python 
 mailing list, not D's NG.

Imperative/OOP languages are not totally different from each other, both Python and D derive strongly from C that comes partially from Algol, and D copies several things from Python (string functions, part of the module system, part of the range design comes from itertools, and so on). So comparing languages and their features is very useful. If you have not used named arguments in languages that idiomatically use them, then it's not easy for you to see how and why they are sometimes useful and good. In Python function arguments don't have a type, so named arguments are more useful than in D. But from my experience in Python, I believe D could enjoy named arguments. Bye, bearophile
Mar 25 2013
prev sibling next sibling parent "foobar" <foo bar.com> writes:
On Monday, 25 March 2013 at 13:02:49 UTC, bearophile wrote:
 foobar:

 "idiomatic" is a relative term, tightly coupled to a specific 
 language. Idiomatic D code for example is very different from 
 idiomatic Haskell code.
 Idiomatic Python style in D would be very unidiomatic D code 
 and vise versa. Each language has its own conventions, styles, 
 set of distinct features, etc, etc and trying to use "language 
 A" style while coding in "language B" is like trying to fit a 
 square peg in a round hole.
 For instance, I would NOT use smalltalk naming conventions 
 while writing say Java code. Both have very good and very 
 consistent styles that are tightly coupled with their 
 respective syntaxes and are very unsuitable to use in the 
 other language.

 In short, if you want to discuss python features, style or 
 specific math plotting libraries, please post to the python 
 mailing list, not D's NG.

Imperative/OOP languages are not totally different from each other, both Python and D derive strongly from C that comes partially from Algol, and D copies several things from Python (string functions, part of the module system, part of the range design comes from itertools, and so on). So comparing languages and their features is very useful. If you have not used named arguments in languages that idiomatically use them, then it's not easy for you to see how and why they are sometimes useful and good. In Python function arguments don't have a type, so named arguments are more useful than in D. But from my experience in Python, I believe D could enjoy named arguments. Bye, bearophile

C is a HORRIBLE language regarding naming conventions and is a *very poor choice* to learn from in this regard. Python sets very high expectations regarding "beautiful code" and IMHO fails miserably (more so because of the starting higher expectations). I admit to being spoiled by actually beautifully designed languages that are far superior in that respect. I suggest to learn Smalltalk for a language that emphasizes code readability decades before Python became cool. I find Ruby which is based on Smalltalk's semantics and spirit to be more elegant and less pretentious compared to Python.
Mar 25 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-03-21 19:35, J wrote:

[snip]

I just noticed that Michel Fortin has implemented basic support for 
named parameters. I've updated his code to the latest DMD and pushed it 
to my fork:

https://github.com/jacob-carlborg/dmd/commit/e363a093040c4b14e7e814027c3e199676c82820

 From the commit message:

Add basic support for named parameters.

This will only allow to add the name of the parameter
when calling a function. It doesn't not support passing
the arguments out of order.

All credit goes to Michel Fortin.

-- 
/Jacob Carlborg
Mar 25 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-03-26 10:31, renoX wrote:

 Interesting, the "doesn't not support passing the arguments out of
 order." can be seen either as a (temporary or not) implementation
 limitation OR as a feature.

I would guess it was easier. At least the change is very small. Smaller that I would have imagined.
 The things to check is how this feature would work with optional
 parameters..

Good point. -- /Jacob Carlborg
Mar 26 2013
prev sibling next sibling parent "J" <notavail notavailable.com> writes:
On Monday, 25 March 2013 at 16:03:38 UTC, Jacob Carlborg wrote:
 On 2013-03-21 19:35, J wrote:

 [snip]

 I just noticed that Michel Fortin has implemented basic support 
 for named parameters. I've updated his code to the latest DMD 
 and pushed it to my fork:

 https://github.com/jacob-carlborg/dmd/commit/e363a093040c4b14e7e814027c3e199676c82820

 From the commit message:

 Add basic support for named parameters.

 This will only allow to add the name of the parameter
 when calling a function. It doesn't not support passing
 the arguments out of order.

 All credit goes to Michel Fortin.

+1000 Excellent!
Mar 25 2013
prev sibling next sibling parent "J" <noone notlisted.notlisted.com> writes:
On Monday, 25 March 2013 at 18:11:54 UTC, J wrote:
 On Monday, 25 March 2013 at 16:03:38 UTC, Jacob Carlborg wrote:
 On 2013-03-21 19:35, J wrote:

 [snip]

 I just noticed that Michel Fortin has implemented basic 
 support for named parameters. I've updated his code to the 
 latest DMD and pushed it to my fork:

 https://github.com/jacob-carlborg/dmd/commit/e363a093040c4b14e7e814027c3e199676c82820

 From the commit message:

 Add basic support for named parameters.

 This will only allow to add the name of the parameter
 when calling a function. It doesn't not support passing
 the arguments out of order.

 All credit goes to Michel Fortin.

+1000 Excellent!

Wow. This is really nice! I added a method to Michel's nice work. You can get it in this branch. https://github.com/glycerine/dmd/tree/namedarg All the dmd test suite then passes. You can now do this: void test (double y, double z, int a, int b, int c, string d) { } void main () { test(y: 33.3, z: 44.4, a: 9999, b: 8888, 7777, // truly optional d:"Yehaw"); } I also tested the passing of named parameters through variadic templates, and there is a little work needed to make them 'named argument' aware. I added a failing test for that, if anyone wants to tackle it. It is dmd/test/compilable/namedarg_vararg.d in the branch above. $ cat namedarg_vararg.d cat namedarg_vararg.d import core.vararg; import std.stdio; void test(A...)(A a) { foreach(t; a) writeln(t); } void main () { test(x:33.3, z: 44.4, a: 9999, b: 8888, 7777, d:"Yehaw"); } $ dmd namedarg_vararg.d namedarg_vararg.d(12): Error: template namedarg_vararg.test(A...)(A a) cannot deduce template function from argument types !()(x:double,z:double,a:int,b:int,int,d:string) $ * * * Wierd and cool: Since the current version requires the exact same positions as names, it is almost like you get extra refined type safety for free. Say I have a function that takes two strings. The compiler can now help me if I mistakenly switch the two... Example: void find(string needle, string haystack) { } void main () { find(haystack: "abcdefg", needle: "def"); } dmd can now helpfully point out: namedarg_haystack.d(6): Error: function namedarg_haystack.find (string needle, string haystack) is not callable using argument types (haystack:string,needle:string) Nice. This has a different feel to it than where the compiler just 'makes it right' for you, but I still really like it. Super readable.
Mar 26 2013
prev sibling next sibling parent "renoX" <renozyx gmail.com> writes:
On Monday, 25 March 2013 at 16:03:38 UTC, Jacob Carlborg wrote:
[cut]
 Add basic support for named parameters.

 This will only allow to add the name of the parameter
 when calling a function. It doesn't not support passing
 the arguments out of order.

 All credit goes to Michel Fortin.

Interesting, the "doesn't not support passing the arguments out of order." can be seen either as a (temporary or not) implementation limitation OR as a feature. The things to check is how this feature would work with optional parameters.. renoX
Mar 26 2013
prev sibling next sibling parent "J" <noname notavailable.notavailabe.com> writes:
On Tuesday, 26 March 2013 at 09:31:53 UTC, renoX wrote:
 The things to check is how this feature would work with 
 optional parameters..

Another thing to check is whether there is enough information in the object files to link across separately compiled objects. Correct me if I'm wrong, but I don't think object files include the names of struct fields, nor the names of argument parameters. You might have to do what objective-C does, which is merge the parameter names into the name of the function.
Mar 26 2013
prev sibling next sibling parent "J" <noname notavailable.notavailabe.com> writes:
On Tuesday, 26 March 2013 at 20:28:39 UTC, J wrote:
 On Tuesday, 26 March 2013 at 09:31:53 UTC, renoX wrote:
 The things to check is how this feature would work with 
 optional parameters..

Another thing to check is whether there is enough information in the object files to link across separately compiled objects. Correct me if I'm wrong, but I don't think object files include the names of struct fields, nor the names of argument parameters. You might have to do what objective-C does, which is merge the parameter names into the name of the function.

Or maybe there are no link time issues. If named parameters are only ever supplying additional type-check-time information, then there would be zero impact at link time. Correct?
Mar 26 2013
prev sibling next sibling parent "J" <noname notavailable.notavailabe.com> writes:
On Tuesday, 26 March 2013 at 12:14:08 UTC, Jacob Carlborg wrote:
 On 2013-03-26 10:31, renoX wrote:

 Interesting, the "doesn't not support passing the arguments 
 out of
 order." can be seen either as a (temporary or not) 
 implementation
 limitation OR as a feature.

I would guess it was easier. At least the change is very small. Smaller that I would have imagined.
 The things to check is how this feature would work with 
 optional
 parameters..

Good point.

Tested this. Seems to work fine with optional parameters. import std.stdio; void test (int a, int b = 24, int c = 12, int d = 6, int e = 3) { writeln(a); writeln(b); writeln(c); writeln(d); writeln(e); } void main () { test(a: 1, 2, c: 9999); } // output: $ ./namedarg_defaults 1 2 9999 6 3
Mar 26 2013
prev sibling next sibling parent Timothee Cour <thelastmammoth gmail.com> writes:
Interesting, the "doesn't not support passing the arguments out of order." can
be seen either as a (temporary or not) implementation >>limitation OR as a
feature.


Named parameters are only interesting if we can skip some optional parameters. This allows the python-like syntax of specifying only a subset of parameters; otherwise this isn't very interesting. This is used heavily in python and makes code * self-documenting * avoids DRY (don't specify unused params) * avoids boilerplate of introducing auxiliary option structs and fields to it Here are just 3 examples that hopefully will convince some that named params are useful and not ugly. ---- //inspired from python's matplotlib; many more options configurable, which are set to reasonable defaults plot(x=1,y=2,color='red',width=3); //here's another one (cf inspired by scons / waf build tools in python) compile(input=["foo.cpp"] , run=true, debug=true, ldflags="-lcurl", output_dir="build"); //other example: setting optional params in a classifier trainSVM(input=X, labels=Y, C=1000, crossValidate=true, loss=squareHingeLoss) ---- Additionally, we should be able to provide arguments out of order and check at compile time that there are no duplicates and no unexistant fields. The code i posted with support for named!plot.x(2).color("red").width(3) did that, and that wasn't hard. So hopefully it won't be easy to support as well skipping, reordering and CT checking with Michel Fortin's shiny syntax. Here are some design decisions to make: given a function void fun(int a,int b=1, int c=2); * whether to support mixing named and non-named arguments in 1 call (python does) fun(0,b=1) * whether to allow both calling conventions: fun(0,1) fun(0,b=1) * whether to allow both calling conventions: fun(0,1) fun(0,b=1) * whether to tag functions callable by named params via attribute (check is done at CT): that'll indicate clearly we want to freeze names in the API named void fun(int a,int b=1, int c=2); * alternatively to above, whether to use ':' instead of '=' in function declaration void fun(int a,int b:1, int c:2); //now it's only callable by name * whether to support skipping and reordering optional args ; I argued we need to for this to be useful enough Timothee Cour
Mar 26 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 27 March 2013 at 03:29:24 UTC, Timothee Cour wrote:
 Named parameters are only interesting if we can skip some 
 optional parameters.
 This allows the python-like syntax of specifying only a subset 
 of
 parameters; otherwise this isn't very interesting. This is used
 heavily in python and makes code
 * self-documenting
 * avoids DRY (don't specify unused params)
 * avoids boilerplate of introducing auxiliary option structs 
 and fields to it

 Here are just 3 examples that hopefully will convince some that 
 named
 params are useful and not ugly.

 ----
 //inspired from python's matplotlib; many more options 
 configurable,
 which are set to reasonable defaults
 plot(x=1,y=2,color='red',width=3);

 //here's another one (cf inspired by scons / waf build tools in 
 python)
 compile(input=["foo.cpp"] , run=true, debug=true, 
 ldflags="-lcurl",
 output_dir="build");

 //other example: setting optional params in a classifier
 trainSVM(input=X, labels=Y, C=1000, crossValidate=true, 
 loss=squareHingeLoss)
 ----

How is that any better than the monadic solution proposed in the thread and that dn't require any language addition ?
Mar 26 2013
prev sibling parent "J" <notavail notavailable.com> writes:
On Wednesday, 27 March 2013 at 03:29:24 UTC, Timothee Cour wrote:
Interesting, the "doesn't not support passing the arguments 
out of order." can be seen either as a (temporary or not) 
implementation >>limitation OR as a feature.


Named parameters are only interesting if we can skip some optional parameters.

I'd say named parameters are *more* interesting with skipping and re-ordering, but still incredibly valuable even without. Let us get them in people's hands first (and start the addiction process going...bwahahaha!) Let people experience first hand how awesome they are in a quick, doable form. (Feel free to contribute code that implements those skipping and re-ordering features...) Status update: I fixed the only known bug, and added a feature. a. Named parameters now flow into variadic template arguments without a hitch. In other words, this compiles: void test(A...)(A a) {} void main () { test(b: 33.3 c: 44.4); } b. There is an name-matching escape mechanism now. It uses _underscores. If your function looks like: void f(int a, int _b) {} then you can call it like this: f(a:1, anyLabelYouWant: 3); (Actually this was necessitated by how dmd treats variadic actual arguments; it calls them _param_0, _param_1, ..., internally. I'm still going to call this escape-mechanism a feature, though.) Here's the latest (see the named_parameters branch specifically) https://github.com/glycerine/dmd/tree/named_parameters This passes all tests. Try it out. Try and break it.
Mar 26 2013