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

Ahh, OK -- understood.

Thanks,
	-- Pete --

On Sat, Nov 01, 2025 at 08:59:17PM +0000, Rory Walsh wrote:
> 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...
> > > >
> >