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

No, absolutely not. These would be aliases. The old opcode names would
still exist.

On Fri, 31 Oct 2025 at 23:17, Pete Goodeve <[email protected]>
wrote:

> Doesn't that completely break the core principle of backwards
> compatibility? Not something that I would consider.
>
>         -- Pete --
>
> On Fri, Oct 31, 2025 at 10:53:47PM +0000, Rory Walsh wrote:
> > We also have shedkwhen and ftsamplebank, which are also ok, I think. I
> > think if we introduce snake case, or any other convention, we need to go
> > all in. Snake case should add an underscore between each word. Following
> > such a scheme would lead to hundreds of opcodes being renamed, e.g.,
> > ft_len, butter_lp, moog_ladder, pd_half, etc. I'm not against it, but I
> > think it must be a complete buy in. Otherwise we end up with a slightly
> > better system, but one that retains some strange inconsistencies.
> >
> > I have to tip my hat to the core developers at this stage. This
> > conversation wouldn't be happening if they hadn't spent so much time
> > cleaning up the core system and updating/rewriting the parser. It's a
> great
> > place we are in now! ☺️
> >
> > On Fri 31 Oct 2025, 17:17 joachim heintz, <[email protected]> wrote:
> >
> > > i totally agree with rory about the importance of such a cleanup.
> > > as to lowercase or snake_case, i'd say:
> > > - in most cases we can keep lowercase
> > > - if the readability is hurted, underscores can be added.
> > >
> > > for instance: ampdb, mtof, bformenc, butbp, pvsynth are good.
> > > osclisten even is ok, i think.
> > >
> > > just to note that for the german keyboard the underscore is not as
> > > elegant as for the english one.
> > >
> > > On 31/10/2025 16:46, Steven Yi wrote:
> > > > I generally prefer snake_case myself these days for Csound coding.
> > > > Perhaps it's because my brain switches somewhat to C conventions when
> > > > I get to time with Csound. Some of the coding in Csound for
> snake_case
> > > > has to do with the lack of namespaces and import system, so families
> > > > of code are denoted with things like zdf_ladder, zdf_2pole, etc.
> which
> > > > might be implemented as zdf::ladder or zdf::2pole in other languages.
> > > >
> > > > On Fri, Oct 31, 2025 at 9:36 AM Rory Walsh <[email protected]> wrote:
> > > >>
> > > >> I agree that they are more readable, but I think switching to
> > > lowerCamelCase or snake_case would be a huge undertaking. I'm
> interested to
> > > hear what others think.
> > > >>
> > > >> On Fri, 31 Oct 2025 at 11:30, Dave Seidel <[email protected]>
> > > wrote:
> > > >>>
> > > >>> As a user, more consistency in naming would be very nice. I don't
> have
> > > a strong preference for any particular form, having had to adapt to
> all of
> > > them at one time or another over the course of my erstwhile career,
> but I
> > > guess I have somewhat of a reference for either lowerCamelCase or
> > > snake_case, as both offer better readability (IMO) than flatcase.
> > > >>>
> > > >>> - Dave
> > > >>>
> > > >>> On Fri, Oct 31, 2025 at 5:47 AM 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...
> > >
>