Re: [Csnd-dev] language cleanup...

I think this is a good discussion. A couple of points:

- there are a few cases where overloading cannot be done, for instance if parameters have same types but different functions. Overall I think it's good to overload as much as possible.

- I would try to keep to the most common format so we need to create/deprecate fewer names

- if we introduce new names to S, b and B, we should do them as aliases not replacements. 

One thing in particular I like to see deprecated is outs/outq/out8 etc as out can handle any number of channels. Same for in and ins etc.

We should also discuss the complete method to handle deprecation from the code sources to the manual.

best
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 31 Oct 2025, at 09:47, Rory Walsh <[email protected]> wrote:
> 
> 
> It would be nice to iron out some inconsistencies in the language before releasing Csound 7. One of these is the scattershot approach to opcode names. Right now we have lowerCamelCase, snake_case, snake+camel case, and the traditional flatcase. It would be nice to choose one, create aliases for all existing opcodes (if this is doable that is), and mark the others as deprecated.
> 
> Another thing that came up yesterday in a different discussion is the number of version 2 opcodes, diskin2, flooper2, etc. We can now easily overload opcodes, which gives us the option of removing the version 2 variants and overloading the originals instead, although we’d need to audit the opcodes first to see if they all have different parameter signatures.
> 
> Something else that was mentioned was the use of uppercase for booleans. bi, bk, booli, boolk, etc., all seem like better fits. Another long-standing inconsistency is the uppercase S for strings. If I’m not mistaken, we could finally change this to :s and keep it in line with other variable types.
> 
> Consistency has a real impact on usability and teaching, making code easier to read and maintain. I think it would be great to try to address this now. I don't mind doing most of the donkey work. We just need to come to some kind of agreement.
> 
> Rory.
> 
> 
> 
> p.s. I'm posting this to the dev-list, but I think this is something the end-users might also like to have some input on...