I know that this subject has been brought up before, but I would like to 
insist: how difficult would it be to add named arguments to csound 
(maybe csound 7?), so that something like the following would be possible?

asig = mincer(atime, kamp, table: ktab, pitch: kpitch, fftsize: 2048)

Right now we rely on the name of the variables or on comments to 
understand what is happening.

This would make code much clearer and readable and would make debugging 
easier. It could even be optional and would work only for opcodes which 
define names for their arguments.

For a recent project I wrote a physical model of an organ pipe in faust. 
Exporting it to csound resulted in more than 30 inputs, and if anything 
changed in the original opcode (for instance, an input was removed or 
added), then great care had to be taken, so as to not feed a wrong value 
to the model. Named arguments would have been a great feature here.

Another use case is the porting of many UGENs from supercollider, which 
has this feature, and accordingly these ugens have many parameters which 
are optional and are given default values. This is not a problem in 
csound. The real issue is that, when the user needs to set a value for 
one of these arguments, all arguments which come before must also be 
defined. With named arguments this would be solved.

Best,
Eduardo Moguillansky

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Can you file a ticket and we’ll look at it? Thanks
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 19 Jan 2017, at 10:17, Eduardo Moguillansky  wrote:
> 
> I know that this subject has been brought up before, but I would like to insist: how difficult would it be to add named arguments to csound (maybe csound 7?), so that something like the following would be possible?
> 
> asig = mincer(atime, kamp, table: ktab, pitch: kpitch, fftsize: 2048)
> 
> Right now we rely on the name of the variables or on comments to understand what is happening.
> 
> This would make code much clearer and readable and would make debugging easier. It could even be optional and would work only for opcodes which define names for their arguments.
> 
> For a recent project I wrote a physical model of an organ pipe in faust. Exporting it to csound resulted in more than 30 inputs, and if anything changed in the original opcode (for instance, an input was removed or added), then great care had to be taken, so as to not feed a wrong value to the model. Named arguments would have been a great feature here.
> 
> Another use case is the porting of many UGENs from supercollider, which has this feature, and accordingly these ugens have many parameters which are optional and are given default values. This is not a problem in csound. The real issue is that, when the user needs to set a value for one of these arguments, all arguments which come before must also be defined. With named arguments this would be solved.
> 
> Best,
> Eduardo Moguillansky
> 
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>       https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here


Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

A great suggestion.

Sent from my iPhone

> On Jan 19, 2017, at 7:11 AM, Victor Lazzarini  wrote:
> 
> Can you file a ticket and we’ll look at it? Thanks
> ========================
> Prof. Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952 
> 
>> On 19 Jan 2017, at 10:17, Eduardo Moguillansky  wrote:
>> 
>> I know that this subject has been brought up before, but I would like to insist: how difficult would it be to add named arguments to csound (maybe csound 7?), so that something like the following would be possible?
>> 
>> asig = mincer(atime, kamp, table: ktab, pitch: kpitch, fftsize: 2048)
>> 
>> Right now we rely on the name of the variables or on comments to understand what is happening.
>> 
>> This would make code much clearer and readable and would make debugging easier. It could even be optional and would work only for opcodes which define names for their arguments.
>> 
>> For a recent project I wrote a physical model of an organ pipe in faust. Exporting it to csound resulted in more than 30 inputs, and if anything changed in the original opcode (for instance, an input was removed or added), then great care had to be taken, so as to not feed a wrong value to the model. Named arguments would have been a great feature here.
>> 
>> Another use case is the porting of many UGENs from supercollider, which has this feature, and accordingly these ugens have many parameters which are optional and are given default values. This is not a problem in csound. The real issue is that, when the user needs to set a value for one of these arguments, all arguments which come before must also be defined. With named arguments this would be solved.
>> 
>> Best,
>> Eduardo Moguillansky
>> 
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>      https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
> 
> 
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I see the ticket filed, thanks!

For background information, I suspect this would be a fairly large
undertaking.  OENTRY would need revision to store names of arguments
(not just types) and default values; the compiler would need to be
modified to process named arguments and validate all required
arguments are set. The OENTRY change would require all opcodes to be
updated.  The new UDO syntax in CS7 is already halfway there for UDOs
at least to define arguments by name for inputs, so that's not too bad
to update.

As a side note, named arguments aren't the only way to go about the
problem.  Another way is to use configuration data structures that are
passed into the opcode.  This happens frequently, IMO, in languages
that don't support named arguments (e.g., C, C++, Java) where once a
certain number of arguments are exceeded, a developer might revise the
function or method to take in a Config class/struct or something like
that. (CS7 does have user-defined types, which might address some of
this for user-code). The comments on this stackoverflow are relevant
to this discussion:

http://softwareengineering.stackexchange.com/questions/52873/named-arguments-parameters-as-a-readability-aid

>From my own practice, I tend to find typing out named arguments slow
and that coding tools that list arguments a faster practice.  I think
named arguments favor readability over writeability, which is
generally great, but live coding situations I find it hinders more
than helps.  I sometimes find code with many named params to also be
very verbose, particularly if I'm using already well-named variables
as arguments to functions. (e.g., oscil(frequency: oscFrequency) vs.
oscil(oscFrequency)).  I also think functions with many arguments to
be quite odd in the first place, but that may just be a personal
preference.

Anyways, just another opinion. I don't have any objections to having
named arguments in Csound though, but thought it worth mentioning
these perspectives.

On Thu, Jan 19, 2017 at 5:17 AM, Eduardo Moguillansky
 wrote:
> I know that this subject has been brought up before, but I would like to
> insist: how difficult would it be to add named arguments to csound (maybe
> csound 7?), so that something like the following would be possible?
>
> asig = mincer(atime, kamp, table: ktab, pitch: kpitch, fftsize: 2048)
>
> Right now we rely on the name of the variables or on comments to understand
> what is happening.
>
> This would make code much clearer and readable and would make debugging
> easier. It could even be optional and would work only for opcodes which
> define names for their arguments.
>
> For a recent project I wrote a physical model of an organ pipe in faust.
> Exporting it to csound resulted in more than 30 inputs, and if anything
> changed in the original opcode (for instance, an input was removed or
> added), then great care had to be taken, so as to not feed a wrong value to
> the model. Named arguments would have been a great feature here.
>
> Another use case is the porting of many UGENs from supercollider, which has
> this feature, and accordingly these ugens have many parameters which are
> optional and are given default values. This is not a problem in csound. The
> real issue is that, when the user needs to set a value for one of these
> arguments, all arguments which come before must also be defined. With named
> arguments this would be solved.
>
> Best,
> Eduardo Moguillansky
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Dear all,

If a Csound IDE supports autocompletion, then named arguments are wonderful.

If they don't, however, then the daunting task of writing all that extra code up is passed onto the user.

I like named arguments, but in assessing its cost, I would ponder that it extends beyond CS7, and into all IDE's, editors, and ultimately users.

Luis

Sent from my iPhone

> On Jan 19, 2017, at 10:31 AM, Steven Yi  wrote:
> 
> I see the ticket filed, thanks!
> 
> For background information, I suspect this would be a fairly large
> undertaking.  OENTRY would need revision to store names of arguments
> (not just types) and default values; the compiler would need to be
> modified to process named arguments and validate all required
> arguments are set. The OENTRY change would require all opcodes to be
> updated.  The new UDO syntax in CS7 is already halfway there for UDOs
> at least to define arguments by name for inputs, so that's not too bad
> to update.
> 
> As a side note, named arguments aren't the only way to go about the
> problem.  Another way is to use configuration data structures that are
> passed into the opcode.  This happens frequently, IMO, in languages
> that don't support named arguments (e.g., C, C++, Java) where once a
> certain number of arguments are exceeded, a developer might revise the
> function or method to take in a Config class/struct or something like
> that. (CS7 does have user-defined types, which might address some of
> this for user-code). The comments on this stackoverflow are relevant
> to this discussion:
> 
> http://softwareengineering.stackexchange.com/questions/52873/named-arguments-parameters-as-a-readability-aid
> 
> From my own practice, I tend to find typing out named arguments slow
> and that coding tools that list arguments a faster practice.  I think
> named arguments favor readability over writeability, which is
> generally great, but live coding situations I find it hinders more
> than helps.  I sometimes find code with many named params to also be
> very verbose, particularly if I'm using already well-named variables
> as arguments to functions. (e.g., oscil(frequency: oscFrequency) vs.
> oscil(oscFrequency)).  I also think functions with many arguments to
> be quite odd in the first place, but that may just be a personal
> preference.
> 
> Anyways, just another opinion. I don't have any objections to having
> named arguments in Csound though, but thought it worth mentioning
> these perspectives.
> 
> On Thu, Jan 19, 2017 at 5:17 AM, Eduardo Moguillansky
>  wrote:
>> I know that this subject has been brought up before, but I would like to
>> insist: how difficult would it be to add named arguments to csound (maybe
>> csound 7?), so that something like the following would be possible?
>> 
>> asig = mincer(atime, kamp, table: ktab, pitch: kpitch, fftsize: 2048)
>> 
>> Right now we rely on the name of the variables or on comments to understand
>> what is happening.
>> 
>> This would make code much clearer and readable and would make debugging
>> easier. It could even be optional and would work only for opcodes which
>> define names for their arguments.
>> 
>> For a recent project I wrote a physical model of an organ pipe in faust.
>> Exporting it to csound resulted in more than 30 inputs, and if anything
>> changed in the original opcode (for instance, an input was removed or
>> added), then great care had to be taken, so as to not feed a wrong value to
>> the model. Named arguments would have been a great feature here.
>> 
>> Another use case is the porting of many UGENs from supercollider, which has
>> this feature, and accordingly these ugens have many parameters which are
>> optional and are given default values. This is not a problem in csound. The
>> real issue is that, when the user needs to set a value for one of these
>> arguments, all arguments which come before must also be defined. With named
>> arguments this would be solved.
>> 
>> Best,
>> Eduardo Moguillansky
>> 
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>       https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
> 
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

For the users, named arguments would be just an optional feature, it is not necessary to use them. From a perspective of reading code, it would be definitely an improvement. Also errors could be more informative.
For opcodes like partikkel, one needs to define "i" variables for all parameters because a simple value makes the code unreadable. Even for an simpler opcode like flooper2, in order to define the loop mode a lot of other parameters need to be defined, which could be left out if named arguments with defaults would be used.

Anyway, that is just my opinion. I guess that because of csound's flexibility almost everyone here uses it in a somewhat different way and with different purposes.

Eduardo

On 19.01.2017 16:55, Vieira Damiani, Luis F wrote:
> Dear all,
>
> If a Csound IDE supports autocompletion, then named arguments are wonderful.
>
> If they don't, however, then the daunting task of writing all that extra code up is passed onto the user.
>
> I like named arguments, but in assessing its cost, I would ponder that it extends beyond CS7, and into all IDE's, editors, and ultimately users.
>
> Luis
>
> Sent from my iPhone
>
> > On Jan 19, 2017, at 10:31 AM, Steven Yi  wrote:
> >
> > I see the ticket filed, thanks!
> >
> > For background information, I suspect this would be a fairly large
> > undertaking.  OENTRY would need revision to store names of arguments
> > (not just types) and default values; the compiler would need to be
> > modified to process named arguments and validate all required
> > arguments are set. The OENTRY change would require all opcodes to be
> > updated.  The new UDO syntax in CS7 is already halfway there for UDOs
> > at least to define arguments by name for inputs, so that's not too bad
> > to update.
> >
> > As a side note, named arguments aren't the only way to go about the
> > problem.  Another way is to use configuration data structures that are
> > passed into the opcode.  This happens frequently, IMO, in languages
> > that don't support named arguments (e.g., C, C++, Java) where once a
> > certain number of arguments are exceeded, a developer might revise the
> > function or method to take in a Config class/struct or something like
> > that. (CS7 does have user-defined types, which might address some of
> > this for user-code). The comments on this stackoverflow are relevant
> > to this discussion:
> >
> > http://softwareengineering.stackexchange.com/questions/52873/named-arguments-parameters-as-a-readability-aid
> >
> > From my own practice, I tend to find typing out named arguments slow
> > and that coding tools that list arguments a faster practice.  I think
> > named arguments favor readability over writeability, which is
> > generally great, but live coding situations I find it hinders more
> > than helps.  I sometimes find code with many named params to also be
> > very verbose, particularly if I'm using already well-named variables
> > as arguments to functions. (e.g., oscil(frequency: oscFrequency) vs.
> > oscil(oscFrequency)).  I also think functions with many arguments to
> > be quite odd in the first place, but that may just be a personal
> > preference.
> >
> > Anyways, just another opinion. I don't have any objections to having
> > named arguments in Csound though, but thought it worth mentioning
> > these perspectives.
> >
> > On Thu, Jan 19, 2017 at 5:17 AM, Eduardo Moguillansky
> >  wrote:
> >> I know that this subject has been brought up before, but I would like to
> >> insist: how difficult would it be to add named arguments to csound (maybe
> >> csound 7?), so that something like the following would be possible?
> >>
> >> asig = mincer(atime, kamp, table: ktab, pitch: kpitch, fftsize: 2048)
> >>
> >> Right now we rely on the name of the variables or on comments to understand
> >> what is happening.
> >>
> >> This would make code much clearer and readable and would make debugging
> >> easier. It could even be optional and would work only for opcodes which
> >> define names for their arguments.
> >>
> >> For a recent project I wrote a physical model of an organ pipe in faust.
> >> Exporting it to csound resulted in more than 30 inputs, and if anything
> >> changed in the original opcode (for instance, an input was removed or
> >> added), then great care had to be taken, so as to not feed a wrong value to
> >> the model. Named arguments would have been a great feature here.
> >>
> >> Another use case is the porting of many UGENs from supercollider, which has
> >> this feature, and accordingly these ugens have many parameters which are
> >> optional and are given default values. This is not a problem in csound. The
> >> real issue is that, when the user needs to set a value for one of these
> >> arguments, all arguments which come before must also be defined. With named
> >> arguments this would be solved.
> >>
> >> Best,
> >> Eduardo Moguillansky
> >>
> >> Csound mailing list
> >> Csound@listserv.heanet.ie
> >> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> >> Send bugs reports to
> >>       https://github.com/csound/csound/issues
> >> Discussions of bugs and features can be posted here
> >
> > Csound mailing list
> > Csound@listserv.heanet.ie
> > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> > Send bugs reports to
> >        https://github.com/csound/csound/issues
> > Discussions of bugs and features can be posted here
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I like the named argument idea very much.

It has a Swift3 vibe to it as well.

I think that coders are getting more and more used to that level of verbosity especially when  "assisted" by auto-completing IDE's like Xcode.

Our own CsoundQt is helping in this way too.
And could help more by "suggesting" argument names from the opcode help

Sent from my iPhone

> On Jan 19, 2017, at 1:37 PM, Eduardo Moguillansky  wrote:
> 
> For the users, named arguments would be just an optional feature, it is not necessary to use them. From a perspective of reading code, it would be definitely an improvement. Also errors could be more informative.
> For opcodes like partikkel, one needs to define "i" variables for all parameters because a simple value makes the code unreadable. Even for an simpler opcode like flooper2, in order to define the loop mode a lot of other parameters need to be defined, which could be left out if named arguments with defaults would be used.
> 
> Anyway, that is just my opinion. I guess that because of csound's flexibility almost everyone here uses it in a somewhat different way and with different purposes.
> 
> Eduardo
> 
>> On 19.01.2017 16:55, Vieira Damiani, Luis F wrote:
>> Dear all,
>> 
>> If a Csound IDE supports autocompletion, then named arguments are wonderful.
>> 
>> If they don't, however, then the daunting task of writing all that extra code up is passed onto the user.
>> 
>> I like named arguments, but in assessing its cost, I would ponder that it extends beyond CS7, and into all IDE's, editors, and ultimately users.
>> 
>> Luis
>> 
>> Sent from my iPhone
>> 
>> > On Jan 19, 2017, at 10:31 AM, Steven Yi  wrote:
>> >
>> > I see the ticket filed, thanks!
>> >
>> > For background information, I suspect this would be a fairly large
>> > undertaking.  OENTRY would need revision to store names of arguments
>> > (not just types) and default values; the compiler would need to be
>> > modified to process named arguments and validate all required
>> > arguments are set. The OENTRY change would require all opcodes to be
>> > updated.  The new UDO syntax in CS7 is already halfway there for UDOs
>> > at least to define arguments by name for inputs, so that's not too bad
>> > to update.
>> >
>> > As a side note, named arguments aren't the only way to go about the
>> > problem.  Another way is to use configuration data structures that are
>> > passed into the opcode.  This happens frequently, IMO, in languages
>> > that don't support named arguments (e.g., C, C++, Java) where once a
>> > certain number of arguments are exceeded, a developer might revise the
>> > function or method to take in a Config class/struct or something like
>> > that. (CS7 does have user-defined types, which might address some of
>> > this for user-code). The comments on this stackoverflow are relevant
>> > to this discussion:
>> >
>> > http://softwareengineering.stackexchange.com/questions/52873/named-arguments-parameters-as-a-readability-aid
>> >
>> > From my own practice, I tend to find typing out named arguments slow
>> > and that coding tools that list arguments a faster practice.  I think
>> > named arguments favor readability over writeability, which is
>> > generally great, but live coding situations I find it hinders more
>> > than helps.  I sometimes find code with many named params to also be
>> > very verbose, particularly if I'm using already well-named variables
>> > as arguments to functions. (e.g., oscil(frequency: oscFrequency) vs.
>> > oscil(oscFrequency)).  I also think functions with many arguments to
>> > be quite odd in the first place, but that may just be a personal
>> > preference.
>> >
>> > Anyways, just another opinion. I don't have any objections to having
>> > named arguments in Csound though, but thought it worth mentioning
>> > these perspectives.
>> >
>> > On Thu, Jan 19, 2017 at 5:17 AM, Eduardo Moguillansky
>> >  wrote:
>> >> I know that this subject has been brought up before, but I would like to
>> >> insist: how difficult would it be to add named arguments to csound (maybe
>> >> csound 7?), so that something like the following would be possible?
>> >>
>> >> asig = mincer(atime, kamp, table: ktab, pitch: kpitch, fftsize: 2048)
>> >>
>> >> Right now we rely on the name of the variables or on comments to understand
>> >> what is happening.
>> >>
>> >> This would make code much clearer and readable and would make debugging
>> >> easier. It could even be optional and would work only for opcodes which
>> >> define names for their arguments.
>> >>
>> >> For a recent project I wrote a physical model of an organ pipe in faust.
>> >> Exporting it to csound resulted in more than 30 inputs, and if anything
>> >> changed in the original opcode (for instance, an input was removed or
>> >> added), then great care had to be taken, so as to not feed a wrong value to
>> >> the model. Named arguments would have been a great feature here.
>> >>
>> >> Another use case is the porting of many UGENs from supercollider, which has
>> >> this feature, and accordingly these ugens have many parameters which are
>> >> optional and are given default values. This is not a problem in csound. The
>> >> real issue is that, when the user needs to set a value for one of these
>> >> arguments, all arguments which come before must also be defined. With named
>> >> arguments this would be solved.
>> >>
>> >> Best,
>> >> Eduardo Moguillansky
>> >>
>> >> Csound mailing list
>> >> Csound@listserv.heanet.ie
>> >> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> >> Send bugs reports to
>> >>       https://github.com/csound/csound/issues
>> >> Discussions of bugs and features can be posted here
>> >
>> > Csound mailing list
>> > Csound@listserv.heanet.ie
>> > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> > Send bugs reports to
>> >        https://github.com/csound/csound/issues
>> > Discussions of bugs and features can be posted here
>> 
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>        https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>> 
> 
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>       https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

i agree that having the option of named arguments would be a great help 
in particular for learning csound.  i experience this with students 
every day: all what helps to get to a more clear, so to say haptic 
feeling about what one of the numerous input arguments means, would help 
a lot.

and as you described, for own usage of opcodes in which one arguments 
may change the whole series, it would be very useful indeed.

so if there were any possibility in the work on cs7, i'd appreciate a lot.

	joachim


On 19/01/17 19:37, Eduardo Moguillansky wrote:
> For the users, named arguments would be just an optional feature, it is
> not necessary to use them. From a perspective of reading code, it would
> be definitely an improvement. Also errors could be more informative.
> For opcodes like partikkel, one needs to define "i" variables for all
> parameters because a simple value makes the code unreadable. Even for an
> simpler opcode like flooper2, in order to define the loop mode a lot of
> other parameters need to be defined, which could be left out if named
> arguments with defaults would be used.
>
> Anyway, that is just my opinion. I guess that because of csound's
> flexibility almost everyone here uses it in a somewhat different way and
> with different purposes.
>
> Eduardo
>
> On 19.01.2017 16:55, Vieira Damiani, Luis F wrote:
>> Dear all,
>>
>> If a Csound IDE supports autocompletion, then named arguments are
>> wonderful.
>>
>> If they don't, however, then the daunting task of writing all that
>> extra code up is passed onto the user.
>>
>> I like named arguments, but in assessing its cost, I would ponder that
>> it extends beyond CS7, and into all IDE's, editors, and ultimately users.
>>
>> Luis
>>
>> Sent from my iPhone
>>
>> > On Jan 19, 2017, at 10:31 AM, Steven Yi  wrote:
>> >
>> > I see the ticket filed, thanks!
>> >
>> > For background information, I suspect this would be a fairly large
>> > undertaking.  OENTRY would need revision to store names of arguments
>> > (not just types) and default values; the compiler would need to be
>> > modified to process named arguments and validate all required
>> > arguments are set. The OENTRY change would require all opcodes to be
>> > updated.  The new UDO syntax in CS7 is already halfway there for UDOs
>> > at least to define arguments by name for inputs, so that's not too bad
>> > to update.
>> >
>> > As a side note, named arguments aren't the only way to go about the
>> > problem.  Another way is to use configuration data structures that are
>> > passed into the opcode.  This happens frequently, IMO, in languages
>> > that don't support named arguments (e.g., C, C++, Java) where once a
>> > certain number of arguments are exceeded, a developer might revise the
>> > function or method to take in a Config class/struct or something like
>> > that. (CS7 does have user-defined types, which might address some of
>> > this for user-code). The comments on this stackoverflow are relevant
>> > to this discussion:
>> >
>> >
>> http://softwareengineering.stackexchange.com/questions/52873/named-arguments-parameters-as-a-readability-aid
>>
>> >
>> > From my own practice, I tend to find typing out named arguments slow
>> > and that coding tools that list arguments a faster practice.  I think
>> > named arguments favor readability over writeability, which is
>> > generally great, but live coding situations I find it hinders more
>> > than helps.  I sometimes find code with many named params to also be
>> > very verbose, particularly if I'm using already well-named variables
>> > as arguments to functions. (e.g., oscil(frequency: oscFrequency) vs.
>> > oscil(oscFrequency)).  I also think functions with many arguments to
>> > be quite odd in the first place, but that may just be a personal
>> > preference.
>> >
>> > Anyways, just another opinion. I don't have any objections to having
>> > named arguments in Csound though, but thought it worth mentioning
>> > these perspectives.
>> >
>> > On Thu, Jan 19, 2017 at 5:17 AM, Eduardo Moguillansky
>> >  wrote:
>> >> I know that this subject has been brought up before, but I would
>> like to
>> >> insist: how difficult would it be to add named arguments to csound
>> (maybe
>> >> csound 7?), so that something like the following would be possible?
>> >>
>> >> asig = mincer(atime, kamp, table: ktab, pitch: kpitch, fftsize: 2048)
>> >>
>> >> Right now we rely on the name of the variables or on comments to
>> understand
>> >> what is happening.
>> >>
>> >> This would make code much clearer and readable and would make
>> debugging
>> >> easier. It could even be optional and would work only for opcodes
>> which
>> >> define names for their arguments.
>> >>
>> >> For a recent project I wrote a physical model of an organ pipe in
>> faust.
>> >> Exporting it to csound resulted in more than 30 inputs, and if
>> anything
>> >> changed in the original opcode (for instance, an input was removed or
>> >> added), then great care had to be taken, so as to not feed a wrong
>> value to
>> >> the model. Named arguments would have been a great feature here.
>> >>
>> >> Another use case is the porting of many UGENs from supercollider,
>> which has
>> >> this feature, and accordingly these ugens have many parameters
>> which are
>> >> optional and are given default values. This is not a problem in
>> csound. The
>> >> real issue is that, when the user needs to set a value for one of
>> these
>> >> arguments, all arguments which come before must also be defined.
>> With named
>> >> arguments this would be solved.
>> >>
>> >> Best,
>> >> Eduardo Moguillansky
>> >>
>> >> Csound mailing list
>> >> Csound@listserv.heanet.ie
>> >> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> >> Send bugs reports to
>> >>       https://github.com/csound/csound/issues
>> >> Discussions of bugs and features can be posted here
>> >
>> > Csound mailing list
>> > Csound@listserv.heanet.ie
>> > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> > Send bugs reports to
>> >        https://github.com/csound/csound/issues
>> > Discussions of bugs and features can be posted here
>>
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>         https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>>
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here