On Tuesday, March 01, 2011 11:22:17 Bekenn wrote:
> On 2/28/11 1:38 PM, Don wrote:
> > 1. It makes parameter names part of the API.
> 
> I wrote earlier that this would probably be the first time parameter names "leaked" into user code, but I was wrong.  Jacob Carlborg has pointed out his library implementation of this feature:
> 
> http://dsource.org/projects/orange/browser/orange/util/Reflection.d#L135
> 
> If you look through his implementation, you'll see that it uses the .stringof property to extract parameter names from the function definition.  In essence, parameter names are /already/ part of the API, because code can be written that depends on them.  And the fact that a library implementation exists specifically to facilitate the use of named arguments implies that code already /has/ been written that depends on parameter names.
> 
> Like it or not, parameter names are already part of the API.  Adding named arguments as a language feature doesn't change that.

You're talking about a third party library that's trying to hack in named arguments, not the language nor the standard library.

The parameter names of a function are _not_ currently part of its signature. You could have a .di file without any parameter names or with totally different parameter names than the original .d file and it would have _zero_ effect on anything calling those functions. The function signature does _not_ include the name of its parameters - just their types. Adding named arguments would change that.

- Jonathan M Davis

On 01.03.2011 20:55, Bekenn wrote:
> On 3/1/11 4:52 AM, Max Samukha wrote:
>> I hate that "explicitness improves code clarity and readability"
>> argument. It may be true in some cases but most of the time explicitness
>> creates unnecessary redundancy that actually impairs readability.
>
> Correct. However, named arguments are not a "most of the time" feature.
> Just look at some Python code, where named arguments have been supported
> for a very long time; you'll still mostly see people making calls using
> positional arguments, which is as it should be. Named arguments are
> there for when they're helpful, and get out of the way when they're not.

I am not against named arguments. What I wanted to say is that writef(formatstr: "...", ) does not make the code more readable. Also, I shudder at the thought that the compiler guys may stop working on the toolchain issues and rush to implement named arguments instead.

Jonathan M Davis Wrote:

> On Tuesday, March 01, 2011 11:22:17 Bekenn wrote:
> > On 2/28/11 1:38 PM, Don wrote:
> > > 1. It makes parameter names part of the API.
> > 
> > I wrote earlier that this would probably be the first time parameter names "leaked" into user code, but I was wrong.  Jacob Carlborg has pointed out his library implementation of this feature:
> > 
> > http://dsource.org/projects/orange/browser/orange/util/Reflection.d#L135
> > 
> > If you look through his implementation, you'll see that it uses the .stringof property to extract parameter names from the function definition.  In essence, parameter names are /already/ part of the API, because code can be written that depends on them.  And the fact that a library implementation exists specifically to facilitate the use of named arguments implies that code already /has/ been written that depends on parameter names.
> > 
> > Like it or not, parameter names are already part of the API.  Adding named arguments as a language feature doesn't change that.
> 
> You're talking about a third party library that's trying to hack in named arguments, not the language nor the standard library.
> 
> The parameter names of a function are _not_ currently part of its signature. You could have a .di file without any parameter names or with totally different parameter names than the original .d file and it would have _zero_ effect on anything calling those functions. The function signature does _not_ include the name of its parameters - just their types. Adding named arguments would change that.
> 
> - Jonathan M Davis


Neither are aliases signatures but they can still be imported. If the library writer choose to expose argument names in the .di file then I'd say they are part of the API.

On 3/2/2011 1:34 AM, Max Samukha wrote:
> I am not against named arguments. What I wanted to say is that
> writef(formatstr: "...", ) does not make the code more readable.

Right, agreed.  This is one of the "not helpful" cases, where you simply don't use named arguments.  I'd expect (and hope for) most function calls to fall into that category.

> Also, I
> shudder at the thought that the compiler guys may stop working on the
> toolchain issues and rush to implement named arguments instead.

I'm only just becoming aware of the scope of the toolchain issues, so I'm not really qualified to comment on that.  This doesn't have to go to the front of the queue, but it'd be nice to see it scheduled for D2.

Jim wrote:
> Jonathan M Davis Wrote:
> 
>> On Tuesday, March 01, 2011 11:22:17 Bekenn wrote:
>>> On 2/28/11 1:38 PM, Don wrote:
>>>> 1. It makes parameter names part of the API.
>>> I wrote earlier that this would probably be the first time parameter
>>> names "leaked" into user code, but I was wrong.  Jacob Carlborg has
>>> pointed out his library implementation of this feature:
>>>
>>> http://dsource.org/projects/orange/browser/orange/util/Reflection.d#L135
>>>
>>> If you look through his implementation, you'll see that it uses the
>>> .stringof property to extract parameter names from the function
>>> definition.  In essence, parameter names are /already/ part of the API,
>>> because code can be written that depends on them.  And the fact that a
>>> library implementation exists specifically to facilitate the use of
>>> named arguments implies that code already /has/ been written that
>>> depends on parameter names.
>>>
>>> Like it or not, parameter names are already part of the API.  Adding
>>> named arguments as a language feature doesn't change that.
>> You're talking about a third party library that's trying to hack in named arguments, not the language nor the standard library.
>>
>> The parameter names of a function are _not_ currently part of its signature. You could have a .di file without any parameter names or with totally different parameter names than the original .d file and it would have _zero_ effect on anything calling those functions. The function signature does _not_ include the name of its parameters - just their types. Adding named arguments would change that.
>>
>> - Jonathan M Davis
> 
> 
> Neither are aliases signatures but they can still be imported. If the library writer choose to expose argument names in the .di file then I'd say they are part of the API.

The library writer has no choice.
Templates function implementation must be included in the .di file. This exposes the parameter names.

The proposal introduces additional coupling between library code and user code, which is useless in the majority of cases.

I can see the value in an opt-in annotation (*not* opt-out) for those problem domains where large numbers of function parameters are normal. But I would strongly oppose it in general.

I find this an interesting discussion.  Coming from writing alot of code in
language that makes extensive and
highly effective use of named arguments (R), I can say that optional named
arguments
(as in Lisp, and descendants like Python and R) do have big software
engineering benefits,
but also come with a substantial costs in terms of complexity of the
function call sequence.

That is, named arguments can be expensive in a typical interpreted
implementation
(probably one reason why R and Python are much slower to execute than the
other
interpreted languages), presumably because each function call has to
invoke hash
table lookups to determine the canonical formal position of each actual
argument, and deal with variadic
cases, to rearrange the order of the arguments to match expectations of the
callee.

Someone familiar with lisp compilers could probably tell you if the heavy
speed tax is intrinsic
or just the price of interpretation.

It would indeed be an interesting challenge to see if the compile-time
metaprogramming
features of D would allow one to include named arguments in an opt-in
fashion without speed reduction.

Jason

On Wed, Mar 2, 2011 at 6:16 AM, Don <nospam@nospam.com> wrote:

> Jim wrote:
>
>> Jonathan M Davis Wrote:
>>
>>  On Tuesday, March 01, 2011 11:22:17 Bekenn wrote:
>>>
>>>> On 2/28/11 1:38 PM, Don wrote:
>>>>
>>>>> 1. It makes parameter names part of the API.
>>>>>
>>>> I wrote earlier that this would probably be the first time parameter names "leaked" into user code, but I was wrong.  Jacob Carlborg has pointed out his library implementation of this feature:
>>>>
>>>> http://dsource.org/projects/orange/browser/orange/util/Reflection.d#L135
>>>>
>>>> If you look through his implementation, you'll see that it uses the .stringof property to extract parameter names from the function definition.  In essence, parameter names are /already/ part of the API, because code can be written that depends on them.  And the fact that a library implementation exists specifically to facilitate the use of named arguments implies that code already /has/ been written that depends on parameter names.
>>>>
>>>> Like it or not, parameter names are already part of the API.  Adding named arguments as a language feature doesn't change that.
>>>>
>>> You're talking about a third party library that's trying to hack in named arguments, not the language nor the standard library.
>>>
>>> The parameter names of a function are _not_ currently part of its signature. You could have a .di file without any parameter names or with totally different parameter names than the original .d file and it would have _zero_ effect on anything calling those functions. The function signature does _not_ include the name of its parameters - just their types. Adding named arguments would change that.
>>>
>>> - Jonathan M Davis
>>>
>>
>>
>> Neither are aliases signatures but they can still be imported. If the library writer choose to expose argument names in the .di file then I'd say they are part of the API.
>>
>
> The library writer has no choice.
> Templates function implementation must be included in the .di file. This
> exposes the parameter names.
>
> The proposal introduces additional coupling between library code and user code, which is useless in the majority of cases.
>
> I can see the value in an opt-in annotation (*not* opt-out) for those problem domains where large numbers of function parameters are normal. But I would strongly oppose it in general.
>
>

On Wed, 02 Mar 2011 08:45:43 -0500, Jason E. Aten <j.e.aten@gmail.com> wrote:

> I find this an interesting discussion.  Coming from writing alot of code in
> language that makes extensive and
> highly effective use of named arguments (R), I can say that optional named
> arguments
> (as in Lisp, and descendants like Python and R) do have big software
> engineering benefits,
> but also come with a substantial costs in terms of complexity of the
> function call sequence.
>
> That is, named arguments can be expensive in a typical interpreted
> implementation
> (probably one reason why R and Python are much slower to execute than the
> other
> interpreted languages), presumably because each function call has to
> invoke hash
> table lookups to determine the canonical formal position of each actual
> argument, and deal with variadic
> cases, to rearrange the order of the arguments to match expectations of the
> callee.
>
> Someone familiar with lisp compilers could probably tell you if the heavy
> speed tax is intrinsic
> or just the price of interpretation.
>
> It would indeed be an interesting challenge to see if the compile-time
> metaprogramming
> features of D would allow one to include named arguments in an opt-in
> fashion without speed reduction.

Considering that calling a function with parameters by name directly translates at compile time to a function call by position, there should be zero speed impact.  The interpretation of the parameter names, which is done at runtime for Python, would be done at compile time in D.

-Steve

Steven Schveighoffer Wrote:

> On Wed, 02 Mar 2011 08:45:43 -0500, Jason E. Aten <j.e.aten@gmail.com> wrote:
> 
> > I find this an interesting discussion.  Coming from writing alot of code
> > in
> > language that makes extensive and
> > highly effective use of named arguments (R), I can say that optional
> > named
> > arguments
> > (as in Lisp, and descendants like Python and R) do have big software
> > engineering benefits,
> > but also come with a substantial costs in terms of complexity of the
> > function call sequence.
> >
> > That is, named arguments can be expensive in a typical interpreted
> > implementation
> > (probably one reason why R and Python are much slower to execute than the
> > other
> > interpreted languages), presumably because each function call has to
> > invoke hash
> > table lookups to determine the canonical formal position of each actual
> > argument, and deal with variadic
> > cases, to rearrange the order of the arguments to match expectations of
> > the
> > callee.
> >
> > Someone familiar with lisp compilers could probably tell you if the heavy
> > speed tax is intrinsic
> > or just the price of interpretation.
> >
> > It would indeed be an interesting challenge to see if the compile-time
> > metaprogramming
> > features of D would allow one to include named arguments in an opt-in
> > fashion without speed reduction.
> 
> Considering that calling a function with parameters by name directly translates at compile time to a function call by position, there should be zero speed impact.  The interpretation of the parameter names, which is done at runtime for Python, would be done at compile time in D.
> 
> -Steve


In addition to that, named template arguments would allow you to create very customizable, yet lean types. It would be possible to parameterize all components. Basically, if you're not pleased with the default search algorithm or container type of a more complex object then you can specify your own.

On Wed, Mar 2, 2011 at 8:45 AM, Jim <bitcirkel@yahoo.com> wrote:
>
> In addition to that, named template arguments would allow you to create very customizable, yet lean types. It would be possible to parameterize all components. Basically, if you're not pleased with the default search algorithm or container type of a more complex object then you can specify your own.
>

Interesting, I hadn't considered the benefits of template arguments with names as far as leanness of types.

The best part of naming arguments for functions and methods, in my experience, is that if you add additional arguments to a method, it is a cheap change. I don't have to go and find and change all the client calls that have already been written. I can leave all of the existing source with client code untouched, and only specify the new parameter in the new invocation that wants to use the new functionality.  I only have to recompile.  Low maintenance.  Nice.

On Wed, 02 Mar 2011 10:06:17 -0500, Jason E. Aten <j.e.aten@gmail.com> wrote:

> On Wed, Mar 2, 2011 at 8:45 AM, Jim <bitcirkel@yahoo.com> wrote:
>>
>> In addition to that, named template arguments would allow you to create
>> very customizable, yet lean types. It would be possible to parameterize all
>> components. Basically, if you're not pleased with the default search
>> algorithm or container type of a more complex object then you can specify
>> your own.
>>
>
> Interesting, I hadn't considered the benefits of template arguments with
> names as far as leanness of types.
>
> The best part of naming arguments for functions and methods, in my
> experience, is that if you add additional arguments to a method, it is a
> cheap change. I don't have to go and find and change all the client calls
> that have already been written. I can leave all of the existing source with
> client code untouched, and only specify the new parameter in the new
> invocation that wants to use the new functionality.  I only have to
> recompile.  Low maintenance.  Nice.

This isn't as dynamic as you think.  If you change a function's argument types or count, the client must recompile.  However, their code shouldn't have to change.

-Steve