There are many opcodes which accept strings and derive some action from 
the string either at i-time, k-time or both. The channel opcodes come to 
mind as the most prominent ones. In some cases, the string is used at 
i-time to, for instance, find a pointer to a channel, decide upon some 
calculation, etc. It would be nice to be able to tell the opcode that 
this string will not mutate and that it is ok to set values at i-time, 
OR, to be able to indicate that the string can change during the 
lifetime of a note (if that makes sense for the given opcode).

I would like to propose that strings prepended with a given character, 
for instance ":" , would be treated as symbols (immutable strings) and 
an opcode could derive i-time actions from this. This would make opcodes 
like chnset able to react to changes in the channel name but still 
efficiently use the current implementation of setting the channel 
pointer at i-time, without the need to do a strcmp at each k-pass.

best regards,

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

To be clear, this proposes more a convention than a modification of the current state. Strings are implemented in a very simple way which makes modern opcodes which deal with strings rather inefficient. In many cases such strings are not meant to change during the lifetime of a note and in fact many opcodes assume that they don't. Since it is not possible to indicate with the type that a string is immutable, it would need a special opcode to accomodate for mutable strings, or, the opcode would need to check at each k-cycle if the string has changed. This proposal would allow the user to communicate if a certain string can mutate or not and thus allow an opcode to react to this by simple checking the first char of the strings value. It would allow for further optimizations, like interning, etc.

Ruby is a good example of a language that isn't very backwards compatible. I like the idea presented here, I would welcome it. I wonder it there's a prettier way to notate this. With an opcode initImmuteableString? Or typehint/typemetadata
Sstring:i = ^immstr "channel1"

Don't know. But colon would be too non-explicit for my taste, idea presented here good! I'm a big fan of immutable data-structures.

On Wed, 6 Nov 2019 at 19:49, Dave Seidel <dave.seidel@gmail.com> wrote:

This syntax is used in Ruby, and perhaps other languages as well, so there's precedent.

On Wed, Nov 6, 2019 at 1:47 PM Rory Walsh <rorywalsh@ear.ie> wrote:

I agree that it would be nice to be able to do this, but I'm not sure I like the idea of prepending strings with a :  

On Wed, 6 Nov 2019 at 11:19, Eduardo Moguillansky <eduardo.moguillansky@gmail.com> wrote:

There are many opcodes which accept strings and derive some action from
the string either at i-time, k-time or both. The channel opcodes come to
mind as the most prominent ones. In some cases, the string is used at
i-time to, for instance, find a pointer to a channel, decide upon some
calculation, etc. It would be nice to be able to tell the opcode that
this string will not mutate and that it is ok to set values at i-time,
OR, to be able to indicate that the string can change during the
lifetime of a note (if that makes sense for the given opcode).

I would like to propose that strings prepended with a given character,
for instance ":" , would be treated as symbols (immutable strings) and
an opcode could derive i-time actions from this. This would make opcodes
like chnset able to react to changes in the channel name but still
efficiently use the current implementation of setting the channel
pointer at i-time, without the need to do a strcmp at each k-pass.

best regards,

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

--

http://mysterybear.net

https://soundcloud.com/mysterybear

https://mysterybear.bandcamp.com

https://www.youtube.com/channel/UCo0--3uN5ycq_aupZXskBgA

http://recordings.irritablehedgehog.com/album/dave-seidel-60-hz

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

So you expect someone to change every opcode that accepts a string as input?

Is it worth it?

⁣Sent from TypeApp ​

On Nov 7, 2019, 09:02, at 09:02, Eduardo Moguillansky  wrote:
>To be clear, this proposes more a convention than a modification of the
>
>current state. Strings are implemented in a very simple way which makes
>
>modern opcodes which deal with strings rather inefficient. In many
>cases 
>such strings are not meant to change during the lifetime of a note and 
>in fact many opcodes assume that they don't. Since it is not possible
>to 
>indicate with the type that a string is immutable, it would need a 
>special opcode to accomodate for mutable strings, or, the opcode would 
>need to check at each k-cycle if the string has changed. This proposal 
>would allow the user to communicate if a certain string can mutate or 
>not and thus allow an opcode to react to this by simple checking the 
>first char of the strings value. It would allow for further 
>optimizations, like interning, etc.
>
>On 07.11.19 02:19, Hlöðver Sigurðsson wrote:
>> Ruby is a good example of a language that isn't very backwards 
>> compatible. I like the idea presented here, I would welcome it. I 
>> wonder it there's a prettier way to notate this. With an opcode 
>> initImmuteableString? Or typehint/typemetadata
>> Sstring:i = ^immstr "channel1"
>>
>> Don't know. But colon would be too non-explicit for my taste, idea 
>> presented here good! I'm a big fan of immutable data-structures.
>>
>> On Wed, 6 Nov 2019 at 19:49, Dave Seidel > > wrote:
>>
>>     This syntax is used in Ruby, and perhaps other languages as well,
>>     so there's precedent.
>>
>>     On Wed, Nov 6, 2019 at 1:47 PM Rory Walsh >     > wrote:
>>
>>         I agree that it would be nice to be able to do this, but I'm
>>         not sure I like the idea of prepending strings with a :
>>
>>         On Wed, 6 Nov 2019 at 11:19, Eduardo Moguillansky
>>         >         > wrote:
>>
>>             There are many opcodes which accept strings and derive
>>             some action from
>>             the string either at i-time, k-time or both. The channel
>>             opcodes come to
>>             mind as the most prominent ones. In some cases, the
>string
>>             is used at
>>             i-time to, for instance, find a pointer to a channel,
>>             decide upon some
>>             calculation, etc. It would be nice to be able to tell the
>>             opcode that
>>             this string will not mutate and that it is ok to set
>>             values at i-time,
>>             OR, to be able to indicate that the string can change
>>             during the
>>             lifetime of a note (if that makes sense for the given
>opcode).
>>
>>             I would like to propose that strings prepended with a
>>             given character,
>>             for instance ":" , would be treated as symbols (immutable
>>             strings) and
>>             an opcode could derive i-time actions from this. This
>>             would make opcodes
>>             like chnset able to react to changes in the channel name
>>             but still
>>             efficiently use the current implementation of setting the
>>             channel
>>             pointer at i-time, without the need to do a strcmp at
>each
>>             k-pass.
>>
>>             best regards,
>>
>>             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 
>>
>>
>>
>>     -- 
>>     http://mysterybear.net
>>     https://soundcloud.com/mysterybear
>>     https://mysterybear.bandcamp.com
>>     https://www.youtube.com/channel/UCo0--3uN5ycq_aupZXskBgA
>>
>>     http://recordings.irritablehedgehog.com/album/dave-seidel-60-hz
>>     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

No, it CAN be used by an opcode developer to decide what kind of 
behaviour is expected. It would make sense in opcodes like chnget and 
chnset which don't accept the name of the channel to change during the 
lifetime of a note. So instead of having to create something like 
chngetk one could specify the expected behaviour by, for example, 
prepending the channel name with a given prefix.

On 07.11.19 13:20, John ff wrote:
> So you expect someone to change every opcode that accepts a string as input?
>
> Is it worth it?
>
> ⁣Sent from TypeApp ​
>
> On Nov 7, 2019, 09:02, at 09:02, Eduardo Moguillansky  wrote:
>> To be clear, this proposes more a convention than a modification of the
>>
>> current state. Strings are implemented in a very simple way which makes
>>
>> modern opcodes which deal with strings rather inefficient. In many
>> cases
>> such strings are not meant to change during the lifetime of a note and
>> in fact many opcodes assume that they don't. Since it is not possible
>> to
>> indicate with the type that a string is immutable, it would need a
>> special opcode to accomodate for mutable strings, or, the opcode would
>> need to check at each k-cycle if the string has changed. This proposal
>> would allow the user to communicate if a certain string can mutate or
>> not and thus allow an opcode to react to this by simple checking the
>> first char of the strings value. It would allow for further
>> optimizations, like interning, etc.
>>
>> On 07.11.19 02:19, Hlöðver Sigurðsson wrote:
>>> Ruby is a good example of a language that isn't very backwards
>>> compatible. I like the idea presented here, I would welcome it. I
>>> wonder it there's a prettier way to notate this. With an opcode
>>> initImmuteableString? Or typehint/typemetadata
>>> Sstring:i = ^immstr "channel1"
>>>
>>> Don't know. But colon would be too non-explicit for my taste, idea
>>> presented here good! I'm a big fan of immutable data-structures.
>>>
>>> On Wed, 6 Nov 2019 at 19:49, Dave Seidel >> > wrote:
>>>
>>>      This syntax is used in Ruby, and perhaps other languages as well,
>>>      so there's precedent.
>>>
>>>      On Wed, Nov 6, 2019 at 1:47 PM Rory Walsh >>      > wrote:
>>>
>>>          I agree that it would be nice to be able to do this, but I'm
>>>          not sure I like the idea of prepending strings with a :
>>>
>>>          On Wed, 6 Nov 2019 at 11:19, Eduardo Moguillansky
>>>          >>          > wrote:
>>>
>>>              There are many opcodes which accept strings and derive
>>>              some action from
>>>              the string either at i-time, k-time or both. The channel
>>>              opcodes come to
>>>              mind as the most prominent ones. In some cases, the
>> string
>>>              is used at
>>>              i-time to, for instance, find a pointer to a channel,
>>>              decide upon some
>>>              calculation, etc. It would be nice to be able to tell the
>>>              opcode that
>>>              this string will not mutate and that it is ok to set
>>>              values at i-time,
>>>              OR, to be able to indicate that the string can change
>>>              during the
>>>              lifetime of a note (if that makes sense for the given
>> opcode).
>>>              I would like to propose that strings prepended with a
>>>              given character,
>>>              for instance ":" , would be treated as symbols (immutable
>>>              strings) and
>>>              an opcode could derive i-time actions from this. This
>>>              would make opcodes
>>>              like chnset able to react to changes in the channel name
>>>              but still
>>>              efficiently use the current implementation of setting the
>>>              channel
>>>              pointer at i-time, without the need to do a strcmp at
>> each
>>>              k-pass.
>>>
>>>              best regards,
>>>
>>>              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
>>>
>>>
>>>
>>>      --
>>>      http://mysterybear.net
>>>      https://soundcloud.com/mysterybear
>>>      https://mysterybear.bandcamp.com
>>>      https://www.youtube.com/channel/UCo0--3uN5ycq_aupZXskBgA
>>>
>>>      http://recordings.irritablehedgehog.com/album/dave-seidel-60-hz
>>>      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