Jarrett Billingsley:
> 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.

I agree that implementing part of the semantics of named arguments is better than nothing. In ShedSkin for example we haven't implemented the argument syntax ** yet (pass by dictionary, not so easy to implement in C++), the full argument pass semantics in Python is quite refined:

def foo(x, y=5, *z, **w):
    print x, y, z, w

foo(10) # Output: 10 5 () {}

foo(10, 20) # Output: 10 20 () {}

foo(10, 20, 30, 40, k=2, j=3) # Output: 10 20 (30, 40) {'k': 2, 'j': 3}

Note that if D becomes more functional, then function pointers/delegates/closures become quite more commonly used. So you are limiting more than you think.

Bye,
bearophile

bearophile escribió:
> 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);

You didn't just replace ":" for "=", you also removed spaces! :P

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

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

See? Now they are the same length.

It's not a matter of preference in D, because "a=b" is an expression, so "=" can't be used for named arguments. I think ":" can, because that is used in statements... and in ?:, but there would be no ambiguities there.

"Denis Koroskin" <2korden@gmail.com> wrote in message news:op.ujsxznwqo7cclz@proton.creatstudio.intranet...
> 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 was just going to bring up the "series of bool params" issue. I very frequently find myself going out of my way to create trivial enums just to avoid using bool parameters.

Similar to named parameters, as much as I normally dislike VB, I've long been jealous of its "optional params can be in the middle" capability.

For instance:
void foo(int a, char[] b, int c=0, char[] d="", int e, char[] f, bool
g=false) {/*...*/}
foo(17, "blah", , , 8.4, "stuff"); // <- Wow!!

That makes it *enormously* easier to design APIs with optional parameters. No more mucking around with potentially-conflicting function overloads just to work around the "optional params must be last" requirement. No more conflict between the desire to organize params in a conceptually-logical order and the need to, again, put the optional params at the end.

Plus, it seems like it would be fairly simple to implement. It's always seemed like a fairly obvious feature to me.

Jarrett Billingsley:

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

In standard Python coding style usually in function calls with named arguments you don't put a space after the equal: foo(x=10)

But I have just seen that after a comma people (like me) usually put a space:
foo(x: 10)

So the second line is a char longer. But I agree it's a not unimportant detail.


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

The following D code gives a syntax error:

import std.stdio: writefln;
int f(int x) { return x + 10; }
void main() {
    writefln( f(x=5) );
}

While this works, and assigns x to 5 in the main:

import std.stdio: writefln;
int f(int x) { return x + 10; }
void main() {
    int x;
    writefln( f(x=5) ); // Output: 15
    writefln(x); // Output: 5
}

In Python x = 5 is never an expression (this precisely to avoid the typical bug of C code of using = instead of ==). And the named arguments don't change the value of the variable in the calling frame:

x = 10
f(x=5)
print x # Output: 10

Overall I agree than the syntax with the colon is probably better for D.
(While a syntax that I don't like much is the .. instead of : to define an array slice).

Bye,
bearophile

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

I don't understand what you mean, in Python if you omit necessary arguments you receive an error:

def foo(x, y=5): print x,y
foo(10, 20) # Output: 10 20
foo(10) # Output: 10 5
foo() # TypeError: foo() takes at least 1 argument (0 given)

Bye,
bearophile

On Wed, Oct 29, 2008 at 4:59 PM, bearophile <bearophileHUGS@lycos.com> wrote:

> So the second line is a char longer. But I agree it's a not unimportant detail.

Double negative "not unimportant" -> "important" ?  ;)  I know, you just made a mistake.

> In Python x = 5 is never an expression (this precisely to avoid the typical bug of C code of using = instead of ==).

OK.

> And the named arguments don't change the value of the variable in the calling frame:
>
> x = 10
> f(x=5)
> print x # Output: 10

I'm not saying that named parameters would in D.  Your example is precisely what I meant by "f(x = 5) already has a well-defined meaning in D."  You're not telling me anything new.

> Overall I agree than the syntax with the colon is probably better for D.
> (While a syntax that I don't like much is the .. instead of : to define an array slice).

In Python, in Python, in Python.  I'm pretty sick of hearing about Python.  D is not Python, D did not come from Python, D is not made to cater to Python users and is not designed for the same things that Python is used for.  Syntactic choices for symbols, operators, or keywords is a completely moot issue.  Please drop it.

"bearophile" <bearophileHUGS@lycos.com> wrote in message news:ge9sf5$1vdc$1@digitalmars.com...
> 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 dissapointed...but not surprised. Looks like the templates are still gimped: I don't see anything about an IArithmetic or operator constraints.

I'm also dissapointed with the focus on dynamic programming as I've really never seen much need for such a thing in a static language (or in any language, IMO). Most people experienced with static typing are probably well aware of the pitfalls dynamic typing introduces, so I won't point them out. And as far as I've seen, the only benefits that can't already be achieved just fine through templates or boxing are just incredibly trivial things like not creating an extra variable to hold the string equivilant of one of your ints.

On Wed, Oct 29, 2008 at 5:14 PM, Nick Sabalausky <a@a.a> wrote:
> And as far as I've seen, the only benefits that can't already be achieved just fine through templates or boxing are just incredibly trivial things like not creating an extra variable to hold the string equivilant of one of your ints.

Er - "holding the string equivalent of an int"?  Which are you arguing against, then: dynamic typing or weak typing?  They are two separate axes of typing systems that are often erroneously conflated..

If you're arguing against weak typing - that is, providing loopholes in the typing system by means of implicit conversions that exist for no other purpose than convenience - I am with you 100%.  Weak typing is an absolute abomination that does not deserve to belong in any language that is to be used as more than a toy.

But if you're arguing against dynamic typing, or more generally dynamic object manipulation, I'm not sure I'd agree.  Dynamic typing does have some very nice use cases - RPC (without having to dynamically generate and compile statically-typed code), database interaction, GUIs (see obj-c), interaction with other dynamically-typed languages, etc.  Having either dynamic or static typing just makes emulating the other a pain or impossible.  Having both gives you the best of both worlds.

Hello Jarrett,

> 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!)


Actually Boo supported the same thing before them. Their IQuakFoo interface it's the equivalent of the IDinamicObject interface in C# 4.

Off course, before that there was ActionScript 3 which mixed both (though dynamic is the default).

Julio César Carrascal Urquijo:
> Actually Boo supported the same thing before them. Their IQuakFoo interface it's the equivalent of the IDinamicObject interface in C# 4.

When the LDC compiler works well (based on LLVM) I think the underlying VM may be used in ways similar to the dotnet VM or the JavaVM, so you can even think about putting in the D language more reflection, some native forms of dynamic generation and compilation of code, that today are possible in C#, macros like ones in Boo, etc.

Bye,
bearophile