Thanks to Reddit I have found a nice short document that lists some of the differences of C#4: https://docs.google.com/View?docid=dcj4xk6_17ffc7nmgv

They have added a dynamic invocation, useful if you want to implement a dynamic language (like IronPython, IronRuby, etc) on top of the dotnet. Object-C shows this is doable in a very C-like language, and the Boo language shows that in a statically typed language it can be useful to use a Duck type once in a while to reduce the "static type pressure". More info on this last concept in the Boo site.

Something that I like a lot is the named arguments, that I hope to see in D and Delight someday. They are used often in Python, and they help increase the readability of the code, sometimes even reducing mistakes.
They have used colons:
foo(x: 1, z: 3)
While Python uses equal signs:
foo(x=1, z=3)
I think they are about equally readable.
(I think there's a problem with named arguments, that you can solve in some ways, for example with an extra hidden bitfield argument that encodes what arguments are given and what not).

Bye,
bearophile

== Quote from bearophile (bearophileHUGS@lycos.com)'s article
> They have used colons:
> foo(x: 1, z: 3)
> While Python uses equal signs:
> foo(x=1, z=3)
> I think they are about equally readable.
> (I think there's a problem with named arguments, that you can solve in some
ways, for example with an extra hidden bitfield argument that encodes what arguments are given and what not).
> Bye,
> bearophile

Vote++ for named arguments.  I've been meaning to bring this up for a while. Given that it's a pure syntactic sugar feature and therefore shouldn't cause any significant ripple effects (at least none that I'm aware of) and greatly simplifies design and use of APIs with lots of optional parameters, I think it's a no brainer.

On Thu, Oct 30, 2008 at 12:18 AM, dsimcha <dsimcha@yahoo.com> wrote:
> == Quote from bearophile (bearophileHUGS@lycos.com)'s article
>> They have used colons:
>> foo(x: 1, z: 3)
>> While Python uses equal signs:
>> foo(x=1, z=3)
>> I think they are about equally readable.
>> (I think there's a problem with named arguments, that you can solve in some
> ways, for example with an extra hidden bitfield argument that encodes what arguments are given and what not).
>> Bye,
>> bearophile
>
> Vote++ for named arguments.  I've been meaning to bring this up for a while. Given that it's a pure syntactic sugar feature and therefore shouldn't cause any significant ripple effects (at least none that I'm aware of) and greatly simplifies design and use of APIs with lots of optional parameters, I think it's a no brainer.

I think it would be nice, but it has come up a few times in the past, and never got much traction.

--bb

On Wed, Oct 29, 2008 at 10:37 AM, bearophile <bearophileHUGS@lycos.com> wrote:
> Thanks to Reddit I have found a nice short document that lists some of the differences of C#4: https://docs.google.com/View?docid=dcj4xk6_17ffc7nmgv
>
> They have added a dynamic invocation, useful if you want to implement a dynamic language (like IronPython, IronRuby, etc) on top of the dotnet. Object-C shows this is doable in a very C-like language, and the Boo language shows that in a statically typed language it can be useful to use a Duck type once in a while to reduce the "static type pressure". More info on this last concept in the Boo site.

Aw, man, they beat me to it.  I always wondered if it would be cool to have a language that supported both static and dynamic programming natively.  It was going to be the "cool thing" in the next language I made ;)  (it probably still will!)

> Something that I like a lot is the named arguments, that I hope to see in D and Delight someday. They are used often in Python, and they help increase the readability of the code, sometimes even reducing mistakes.
> They have used colons:
> foo(x: 1, z: 3)
> While Python uses equal signs:
> foo(x=1, z=3)
> I think they are about equally readable.
> (I think there's a problem with named arguments, that you can solve in some ways, for example with an extra hidden bitfield argument that encodes what arguments are given and what not).

Or, you could enforce that named arguments must all have default
values, or that they must _all_ be given when the function is called.
Since it's getting resolved at compile time, no bitfield is necessary.
 It's the same thing as arguments with default values -- all the
compiler does is it inserts the default values at the call site.

Named parameters are very cool, though, and are invaluable for things like GUI APIs.  Combined with structs, they can also remove the need for a separate struct literal syntax.  S(x: 5, y: 10) looks pretty damn nice.

Jarrett Billingsley:
> Since it's getting resolved at compile time, no bitfield is necessary.

When we have designed ShedSkin we have had to deal with named arguments too, including situations like:

import sys
def foo(a, b): return a - b
def bar(b, a): return a / b
fun = [foo, bar]
if sys.argv[1] == "1":
    fun[0], fun[1] = fun[1], fun[0]
print fun[0](a=5.0, b=3.0)

The relative input/output:
C:\>args.py 0
2.0
C:\>args.py 1
1.66666666667

Bye,
bearophile

On Wed, 29 Oct 2008 17:37:25 +0300, bearophile <bearophileHUGS@lycos.com> wrote:

> Thanks to Reddit I have found a nice short document that lists some of the differences of C#4:
> https://docs.google.com/View?docid=dcj4xk6_17ffc7nmgv
>
> They have added a dynamic invocation, useful if you want to implement a dynamic language (like IronPython, IronRuby, etc) on top of the dotnet. Object-C shows this is doable in a very C-like language, and the Boo language shows that in a statically typed language it can be useful to use a Duck type once in a while to reduce the "static type pressure". More info on this last concept in the Boo site.
>
> Something that I like a lot is the named arguments, that I hope to see in D and Delight someday. They are used often in Python, and they help increase the readability of the code, sometimes even reducing mistakes.
> They have used colons:
> foo(x: 1, z: 3)
> While Python uses equal signs:
> foo(x=1, z=3)
> I think they are about equally readable.
> (I think there's a problem with named arguments, that you can solve in some ways, for example with an extra hidden bitfield argument that encodes what arguments are given and what not).
>
> Bye,
> bearophile

I'm waiting for named arguments, too! They make could more readable and self-documenting:
graphicsDevice->updateSettings(true, true, false, true); // wtf??

Compare to the following:
graphicsDevice->updateSettings(fullScreen: true, verticalSync: true, enableBloom: false, fullScreenAA: true);

I once had the following Color class:

class Color
{
    this (byte alpha, byte red, byte green, byte blue) { ... }
}

and used it as follows:

Color c = new Color(255, 0, 255, 0); // opaque green color

After refactoring, alpha became last argument in ctor:

    this(byte red, byte green, byte blue, byte alpha) { ... }

Note that this change didn't raise any compilation error, nothing that would notify my of possible error.

Needless to say that I didn't enjoy searching all the code that used Color to reorder parameters (although some artifact were nice :)
It would save me quite some time if I initialized all my instances as follows:

Color c = new Color(alpha: 255, red: 0, green: 255, blue: 0);

Now compiler could raise an error if parameters order was changed. Even better - compiler could reorder parameters for me automatically if given that all of them are specified and no params ommited (unlike Python). This makes code more robust to refactoring.

On Wed, Oct 29, 2008 at 3:50 PM, bearophile <bearophileHUGS@lycos.com> wrote:
> Jarrett Billingsley:
>> Since it's getting resolved at compile time, no bitfield is necessary.
>
> When we have designed ShedSkin we have had to deal with named arguments too, including situations like:

Ooh, that's icky.  Well I'd argue then that in the equivalent in D:

float foo(float a, float b) { return a - b; }
float bar(float b, float a) { return a / b; }
auto fun = [&foo, &bar];
...
fun[0](a: 5, b: 3); // error

the last line would be an error only because function pointers are not the same as functions, and their parameters do not have names. Similar to how currently, a function pointer or delegate to a function that takes optional parameters cannot be called the same way as the original function.

Still, "only" being able to call functions directly while using named/default parameters covers a _great_ majority of use cases. Covering the rest seems to be wasting a lot of implementation time and performance on something that most people honestly will not use that much.

Denis Koroskin:

> graphicsDevice->updateSettings(fullScreen: true, verticalSync: true, enableBloom: false, fullScreenAA: true);

Seeing this, now I think the syntax with equals is a little shorter, so maybe I prefer the equals:

graphicsDevice->updateSettings(fullScreen=true, verticalSync=true, enableBloom=false, fullScreenAA=true);


> compiler could reorder parameters for me automatically if given that all of them are specified and no params ommited (unlike Python).

Maybe I don't understand what you are saying, but Python too reorders arguments.

Bye,
bearophile

On Wed, 29 Oct 2008 23:28:25 +0300, bearophile <bearophileHUGS@lycos.com> wrote:

> Denis Koroskin:
>
>> graphicsDevice->updateSettings(fullScreen: true, verticalSync: true,
>> enableBloom: false, fullScreenAA: true);
>
> Seeing this, now I think the syntax with equals is a little shorter, so maybe I prefer the equals:
>
> graphicsDevice->updateSettings(fullScreen=true, verticalSync=true,
> enableBloom=false, fullScreenAA=true);
>
>
>> compiler could reorder parameters for me automatically if given
>> that all of them are specified and no params ommited (unlike Python).
>
> Maybe I don't understand what you are saying, but Python too reorders arguments.

"unlike Python" is related to omitting parameters. Python allows that but it doesn't really fit statically typed langugages, I believe.

>
> Bye,
> bearophile

On Wed, Oct 29, 2008 at 4:28 PM, bearophile <bearophileHUGS@lycos.com> wrote:
> Denis Koroskin:
>
>> graphicsDevice->updateSettings(fullScreen: true, verticalSync: true, enableBloom: false, fullScreenAA: true);
>
> Seeing this, now I think the syntax with equals is a little shorter, so maybe I prefer the equals:
>
> graphicsDevice->updateSettings(fullScreen=true, verticalSync=true, enableBloom=false, fullScreenAA=true);

Er, what?  They are exactly the same size..

Besides, = is already an expression in D.  f(x = 5) has a well-defined
meaning already.