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

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...
> >