hi all -

i am so excited to see hlodver pushing a lot of stuff to the cs7
branches (and some already on dhe develop branch).  i'd be curious to
check some things out: are there any descriptions or tests from shich i
can learn what is new?

cheers -
        joachim

super --- thanks for the great description.  hope you can go on with
this important work.

if you can send from time to time a link to a test file (as the ones you
send in your email), it would be wonderful.  i can test then, and these
are already stones for the CS7 version of the floss manual.

for the switch statement, i think "endsw" is a reasonable decision, and
as you say, in line with "endin" and others.

for the array example, i was a bit irritated that for-of seems to be the
same as for-in in python.  (and if i get it right, for-in will return
the index, so similar to enumerate in python.)  but i am sure there will
be a big discussion in the javascript community about it already, and i
am sure that you and the other core devs will find a good solution, with
less possibile confusion.

        joachim


On 28/12/2022 23:17, Hlöðver Sigurðsson wrote:
> thanks for the cheers joachim :)
>
> I've been flooding PRs last weeks, Steven found some time not long ago
> to review some fixes, and that is merged into develop now.
> The change there is quite minimal, it's about allowing a syntax where
> you can get an index from an array where it's inlined with an udo/opcode
> which returns an array.
>
> e.g.
>
> ival = udoReturningArray()[0]
>
> there are two recently opened PRs which I would love feedback on from
> any direction.
>
> Today I made a PR for building switch statements, which are
> stitched together with goto operators,
> it currently works for both i-rate signals and performance rate signals.
> And here comes my opinionated design
> on this, which is that, I don't have switch:k vs switch:i it's just one
> switch operator and the rate of the signal which
> is being compared for, determined the rate of which the switch statement
> runs, which translates to cgotok vs cgoto.
>
> Another opinionated design, which can be discussed deeper, is to match
> switch with an endsw
>
>    switch 3
>      case 0, 2
>        prints "fail\n"
>      case 1, 3
>        prints "pass\n"
>      default
>       prints "fail\n"
>    endsw
>
> I felt endswitch was a mouthful, the word end was kinda out of style
> with other csound block enders, like endif/enduntil/endinst/endop etc.
> But this increases the amount of syntax the user needs to memorize, but
> maybe it's not an issue when it's a pattern in the language.
>
> I also wanted to allow "case" statement/s to be a list of expressions
> with which the switch value is compared against, saving further on line
> counts
> when two cases need to do the exact same thing.
>
> You can test this while it's under review, by checking out the branch
> feature/switch-case-operator and run the commandline test I wrote for
> this feature
> https://github.com/csound/csound/blob/040eb9a809f758775c63a9b6318958189ef0b83d/tests/commandline/test_switch_statement.csd <https://github.com/csound/csound/blob/040eb9a809f758775c63a9b6318958189ef0b83d/tests/commandline/test_switch_statement.csd>
>
> Before I went on xmas holiday I opened another similar PR for for-of
> loops, you could test that my checking out feature/for-of-iterator
> and test the feture with this commandline testfile
> https://github.com/csound/csound/blob/7408361c69b806f675e21d08eff48341e6599273/tests/commandline/arrays/arrays_for_loop.csd <https://github.com/csound/csound/blob/7408361c69b806f675e21d08eff48341e6599273/tests/commandline/arrays/arrays_for_loop.csd>
>
> this for-of loop would only work for arrays, and would be all in all
> exactly the same as you'd expect in javascript with for-of loops there.
>
> The other PRs are mostly fixes and completion of new features. But I'm
> eager to use the time over the holidays to learn C and help with getting
> csound7 further.
>
>
> On Wed, 28 Dec 2022 at 21:26, joachim heintz <jh@joachimheintz.de
> <mailto:jh@joachimheintz.de>> wrote:
>
>     hi all -
>
>     i am so excited to see hlodver pushing a lot of stuff to the cs7
>     branches (and some already on dhe develop branch).  i'd be curious to
>     check some things out: are there any descriptions or tests from shich i
>     can learn what is new?
>
>     cheers -
>              joachim
>

but i am sure there will
be a big discussion in the javascript community about it already, and i
am sure that you and the other core devs will find a good solution, with
less possibile confusion.

correct. I could say this is a better solution because javascript is bigger, but then I can also quote a
funny quote "eat shit, million flies can't be wrong" :)

I will maybe do some digging on why for-of was picked to iterate arrays and not for-in, in javascript
for-in also exists but iterates over objects. Maybe it was used only because of that, that it was already
used for other things. But maybe as well, for-of is the better syntax and python chose for-in for the wrong
reasons. In csound, "in" is already an opcode, I haven't tried using "in" for these sort of loops, but I hope
this won't create ambiguity in the parser. All said and done, I've nothing against using for-in and not for-of,
I'll read more and form a better opinion, like comparing multiple language designs. But I also had in mind
to add for-in for iterating over structs like one would do in javascript for objects, maybe this can all be overloaded
into unified for-in syntax...

Adding the index as additional (optional) output argument is something I had in mind too. I could add that into the open PR or do it soon after it's merged.

I'm not making the lives easy for the reviewers, but as soon as I have some reviews we should start seeing these features merged,
and then it will be easier to test, and yes I'll maybe notify here on csound-devs mailing list on what can be tested :)

On Thu, 29 Dec 2022 at 09:56, joachim heintz <jh@joachimheintz.de> wrote:

super --- thanks for the great description.  hope you can go on with
this important work.

if you can send from time to time a link to a test file (as the ones you
send in your email), it would be wonderful.  i can test then, and these
are already stones for the CS7 version of the floss manual.

for the switch statement, i think "endsw" is a reasonable decision, and
as you say, in line with "endin" and others.

for the array example, i was a bit irritated that for-of seems to be the
same as for-in in python.  (and if i get it right, for-in will return
the index, so similar to enumerate in python.)  but i am sure there will
be a big discussion in the javascript community about it already, and i
am sure that you and the other core devs will find a good solution, with
less possibile confusion.

        joachim


On 28/12/2022 23:17, Hlöðver Sigurðsson wrote:
> thanks for the cheers joachim :)
>
> I've been flooding PRs last weeks, Steven found some time not long ago
> to review some fixes, and that is merged into develop now.
> The change there is quite minimal, it's about allowing a syntax where
> you can get an index from an array where it's inlined with an udo/opcode
> which returns an array.
>
> e.g.
>
> ival = udoReturningArray()[0]
>
> there are two recently opened PRs which I would love feedback on from
> any direction.
>
> Today I made a PR for building switch statements, which are
> stitched together with goto operators,
> it currently works for both i-rate signals and performance rate signals.
> And here comes my opinionated design
> on this, which is that, I don't have switch:k vs switch:i it's just one
> switch operator and the rate of the signal which
> is being compared for, determined the rate of which the switch statement
> runs, which translates to cgotok vs cgoto.
>
> Another opinionated design, which can be discussed deeper, is to match
> switch with an endsw
>
>    switch 3
>      case 0, 2
>        prints "fail\n"
>      case 1, 3
>        prints "pass\n"
>      default
>       prints "fail\n"
>    endsw
>
> I felt endswitch was a mouthful, the word end was kinda out of style
> with other csound block enders, like endif/enduntil/endinst/endop etc.
> But this increases the amount of syntax the user needs to memorize, but
> maybe it's not an issue when it's a pattern in the language.
>
> I also wanted to allow "case" statement/s to be a list of expressions
> with which the switch value is compared against, saving further on line
> counts
> when two cases need to do the exact same thing.
>
> You can test this while it's under review, by checking out the branch
> feature/switch-case-operator and run the commandline test I wrote for
> this feature
> https://github.com/csound/csound/blob/040eb9a809f758775c63a9b6318958189ef0b83d/tests/commandline/test_switch_statement.csd <https://github.com/csound/csound/blob/040eb9a809f758775c63a9b6318958189ef0b83d/tests/commandline/test_switch_statement.csd>
>
> Before I went on xmas holiday I opened another similar PR for for-of
> loops, you could test that my checking out feature/for-of-iterator
> and test the feture with this commandline testfile
> https://github.com/csound/csound/blob/7408361c69b806f675e21d08eff48341e6599273/tests/commandline/arrays/arrays_for_loop.csd <https://github.com/csound/csound/blob/7408361c69b806f675e21d08eff48341e6599273/tests/commandline/arrays/arrays_for_loop.csd>
>
> this for-of loop would only work for arrays, and would be all in all
> exactly the same as you'd expect in javascript with for-of loops there.
>
> The other PRs are mostly fixes and completion of new features. But I'm
> eager to use the time over the holidays to learn C and help with getting
> csound7 further.
>
>
> On Wed, 28 Dec 2022 at 21:26, joachim heintz <jh@joachimheintz.de
> <mailto:jh@joachimheintz.de>> wrote:
>
>     hi all -
>
>     i am so excited to see hlodver pushing a lot of stuff to the cs7
>     branches (and some already on dhe develop branch).  i'd be curious to
>     check some things out: are there any descriptions or tests from shich i
>     can learn what is new?
>
>     cheers -
>              joachim
>

I don't think I need much more researching, I read this article and the comments to it are the most valuable
https://dev.to/rattanakchea/for-loop-for-different-programming-languages-bgb

There it becomes clear, that for-in is used in ruby, swift, python, rust and probably more.
So I'm pretty sold on the for-in in favor of the for-of. It seem that it is indeed the case that 
for-of was chosen in javascript because it arrived later and behaves dramatically different,
using iterable property of any object type (Map, Sets and Objects).

Will adapt this in my PR :)

On Thu, 29 Dec 2022 at 16:05, Hlöðver Sigurðsson <hlolli@gmail.com> wrote:

but i am sure there will
be a big discussion in the javascript community about it already, and i
am sure that you and the other core devs will find a good solution, with
less possibile confusion.

correct. I could say this is a better solution because javascript is bigger, but then I can also quote a
funny quote "eat shit, million flies can't be wrong" :)

I will maybe do some digging on why for-of was picked to iterate arrays and not for-in, in javascript
for-in also exists but iterates over objects. Maybe it was used only because of that, that it was already
used for other things. But maybe as well, for-of is the better syntax and python chose for-in for the wrong
reasons. In csound, "in" is already an opcode, I haven't tried using "in" for these sort of loops, but I hope
this won't create ambiguity in the parser. All said and done, I've nothing against using for-in and not for-of,
I'll read more and form a better opinion, like comparing multiple language designs. But I also had in mind
to add for-in for iterating over structs like one would do in javascript for objects, maybe this can all be overloaded
into unified for-in syntax...

Adding the index as additional (optional) output argument is something I had in mind too. I could add that into the open PR or do it soon after it's merged.

I'm not making the lives easy for the reviewers, but as soon as I have some reviews we should start seeing these features merged,
and then it will be easier to test, and yes I'll maybe notify here on csound-devs mailing list on what can be tested :)

On Thu, 29 Dec 2022 at 09:56, joachim heintz <jh@joachimheintz.de> wrote:

super --- thanks for the great description.  hope you can go on with
this important work.

if you can send from time to time a link to a test file (as the ones you
send in your email), it would be wonderful.  i can test then, and these
are already stones for the CS7 version of the floss manual.

for the switch statement, i think "endsw" is a reasonable decision, and
as you say, in line with "endin" and others.

for the array example, i was a bit irritated that for-of seems to be the
same as for-in in python.  (and if i get it right, for-in will return
the index, so similar to enumerate in python.)  but i am sure there will
be a big discussion in the javascript community about it already, and i
am sure that you and the other core devs will find a good solution, with
less possibile confusion.

        joachim


On 28/12/2022 23:17, Hlöðver Sigurðsson wrote:
> thanks for the cheers joachim :)
>
> I've been flooding PRs last weeks, Steven found some time not long ago
> to review some fixes, and that is merged into develop now.
> The change there is quite minimal, it's about allowing a syntax where
> you can get an index from an array where it's inlined with an udo/opcode
> which returns an array.
>
> e.g.
>
> ival = udoReturningArray()[0]
>
> there are two recently opened PRs which I would love feedback on from
> any direction.
>
> Today I made a PR for building switch statements, which are
> stitched together with goto operators,
> it currently works for both i-rate signals and performance rate signals.
> And here comes my opinionated design
> on this, which is that, I don't have switch:k vs switch:i it's just one
> switch operator and the rate of the signal which
> is being compared for, determined the rate of which the switch statement
> runs, which translates to cgotok vs cgoto.
>
> Another opinionated design, which can be discussed deeper, is to match
> switch with an endsw
>
>    switch 3
>      case 0, 2
>        prints "fail\n"
>      case 1, 3
>        prints "pass\n"
>      default
>       prints "fail\n"
>    endsw
>
> I felt endswitch was a mouthful, the word end was kinda out of style
> with other csound block enders, like endif/enduntil/endinst/endop etc.
> But this increases the amount of syntax the user needs to memorize, but
> maybe it's not an issue when it's a pattern in the language.
>
> I also wanted to allow "case" statement/s to be a list of expressions
> with which the switch value is compared against, saving further on line
> counts
> when two cases need to do the exact same thing.
>
> You can test this while it's under review, by checking out the branch
> feature/switch-case-operator and run the commandline test I wrote for
> this feature
> https://github.com/csound/csound/blob/040eb9a809f758775c63a9b6318958189ef0b83d/tests/commandline/test_switch_statement.csd <https://github.com/csound/csound/blob/040eb9a809f758775c63a9b6318958189ef0b83d/tests/commandline/test_switch_statement.csd>
>
> Before I went on xmas holiday I opened another similar PR for for-of
> loops, you could test that my checking out feature/for-of-iterator
> and test the feture with this commandline testfile
> https://github.com/csound/csound/blob/7408361c69b806f675e21d08eff48341e6599273/tests/commandline/arrays/arrays_for_loop.csd <https://github.com/csound/csound/blob/7408361c69b806f675e21d08eff48341e6599273/tests/commandline/arrays/arrays_for_loop.csd>
>
> this for-of loop would only work for arrays, and would be all in all
> exactly the same as you'd expect in javascript with for-of loops there.
>
> The other PRs are mostly fixes and completion of new features. But I'm
> eager to use the time over the holidays to learn C and help with getting
> csound7 further.
>
>
> On Wed, 28 Dec 2022 at 21:26, joachim heintz <jh@joachimheintz.de
> <mailto:jh@joachimheintz.de>> wrote:
>
>     hi all -
>
>     i am so excited to see hlodver pushing a lot of stuff to the cs7
>     branches (and some already on dhe develop branch).  i'd be curious to
>     check some things out: are there any descriptions or tests from shich i
>     can learn what is new?
>
>     cheers -
>              joachim
>

super cool.  i checked out this branch, and all works perfectly.  so
useful to have the index as optional second output!

just a minor thing: it complained about illegal use of carry in the
score.  i will send you a pull request.


On 29/12/2022 17:14, Hlöðver Sigurðsson wrote:
> ok I updated the PR, now it's using for-in, and it's now possible to
> declare an optional second identifier for assigning the current index to
> a variable,
> see the example here
> https://github.com/csound/csound/blob/28d26a01b4b66b6e7e61c601f8c2e77c916b3d83/tests/commandline/arrays/arrays_for_loop.csd#L42-L47 <https://github.com/csound/csound/blob/28d26a01b4b66b6e7e61c601f8c2e77c916b3d83/tests/commandline/arrays/arrays_for_loop.csd#L42-L47>
>
> On Thu, 29 Dec 2022 at 16:23, Hlöðver Sigurðsson <hlolli@gmail.com
> <mailto:hlolli@gmail.com>> wrote:
>
>     I don't think I need much more researching, I read this article and
>     the comments to it are the most valuable
>     https://dev.to/rattanakchea/for-loop-for-different-programming-languages-bgb <https://dev.to/rattanakchea/for-loop-for-different-programming-languages-bgb>
>
>     There it becomes clear, that for-in is used in ruby, swift, python,
>     rust and probably more.
>     So I'm pretty sold on the for-in in favor of the for-of. It seem
>     that it is indeed the case that
>     for-of was chosen in javascript because it arrived later and behaves
>     dramatically different,
>     using iterable property of any object type (Map, Sets and Objects).
>
>     Will adapt this in my PR :)
>
>     On Thu, 29 Dec 2022 at 16:05, Hlöðver Sigurðsson <hlolli@gmail.com
>     <mailto:hlolli@gmail.com>> wrote:
>
>             but i am sure there will
>             be a big discussion in the javascript community about it
>             already, and i
>             am sure that you and the other core devs will find a good
>             solution, with
>             less possibile confusion.
>
>
>         correct. I could say this is a better solution because
>         javascript is bigger, but then I can also quote a
>         funny quote "eat shit, million flies can't be wrong" :)
>
>         I will maybe do some digging on why for-of was picked to iterate
>         arrays and not for-in, in javascript
>         for-in also exists but iterates over objects. Maybe it was used
>         only because of that, that it was already
>         used for other things. But maybe as well, for-of is the better
>         syntax and python chose for-in for the wrong
>         reasons. In csound, "in" is already an opcode, I haven't tried
>         using "in" for these sort of loops, but I hope
>         this won't create ambiguity in the parser. All said and done,
>         I've nothing against using for-in and not for-of,
>         I'll read more and form a better opinion, like comparing
>         multiple language designs. But I also had in mind
>         to add for-in for iterating over structs like one would do in
>         javascript for objects, maybe this can all be overloaded
>         into unified for-in syntax...
>
>         Adding the index as additional (optional) output argument is
>         something I had in mind too. I could add that into the open PR
>         or do it soon after it's merged.
>
>         I'm not making the lives easy for the reviewers, but as soon as
>         I have some reviews we should start seeing these features merged,
>         and then it will be easier to test, and yes I'll maybe notify
>         here on csound-devs mailing list on what can be tested :)
>
>
>         On Thu, 29 Dec 2022 at 09:56, joachim heintz
>         <jh@joachimheintz.de <mailto:jh@joachimheintz.de>> wrote:
>
>             super --- thanks for the great description.  hope you can go
>             on with
>             this important work.
>
>             if you can send from time to time a link to a test file (as
>             the ones you
>             send in your email), it would be wonderful.  i can test
>             then, and these
>             are already stones for the CS7 version of the floss manual.
>
>             for the switch statement, i think "endsw" is a reasonable
>             decision, and
>             as you say, in line with "endin" and others.
>
>             for the array example, i was a bit irritated that for-of
>             seems to be the
>             same as for-in in python.  (and if i get it right, for-in
>             will return
>             the index, so similar to enumerate in python.)  but i am
>             sure there will
>             be a big discussion in the javascript community about it
>             already, and i
>             am sure that you and the other core devs will find a good
>             solution, with
>             less possibile confusion.
>
>                      joachim
>
>
>             On 28/12/2022 23:17, Hlöðver Sigurðsson wrote:
>              > thanks for the cheers joachim :)
>              >
>              > I've been flooding PRs last weeks, Steven found some time
>             not long ago
>              > to review some fixes, and that is merged into develop now.
>              > The change there is quite minimal, it's about allowing a
>             syntax where
>              > you can get an index from an array where it's inlined
>             with an udo/opcode
>              > which returns an array.
>              >
>              > e.g.
>              >
>              > ival = udoReturningArray()[0]
>              >
>              > there are two recently opened PRs which I would love
>             feedback on from
>              > any direction.
>              >
>              > Today I made a PR for building switch statements, which are
>              > stitched together with goto operators,
>              > it currently works for both i-rate signals and
>             performance rate signals.
>              > And here comes my opinionated design
>              > on this, which is that, I don't have switch:k vs switch:i
>             it's just one
>              > switch operator and the rate of the signal which
>              > is being compared for, determined the rate of which the
>             switch statement
>              > runs, which translates to cgotok vs cgoto.
>              >
>              > Another opinionated design, which can be discussed
>             deeper, is to match
>              > switch with an endsw
>              >
>              >    switch 3
>              >      case 0, 2
>              >        prints "fail\n"
>              >      case 1, 3
>              >        prints "pass\n"
>              >      default
>              >       prints "fail\n"
>              >    endsw
>              >
>              > I felt endswitch was a mouthful, the word end was kinda
>             out of style
>              > with other csound block enders, like
>             endif/enduntil/endinst/endop etc.
>              > But this increases the amount of syntax the user needs to
>             memorize, but
>              > maybe it's not an issue when it's a pattern in the language.
>              >
>              > I also wanted to allow "case" statement/s to be a list of
>             expressions
>              > with which the switch value is compared against, saving
>             further on line
>              > counts
>              > when two cases need to do the exact same thing.
>              >
>              > You can test this while it's under review, by checking
>             out the branch
>              > feature/switch-case-operator and run the commandline test
>             I wrote for
>              > this feature
>              >
>             https://github.com/csound/csound/blob/040eb9a809f758775c63a9b6318958189ef0b83d/tests/commandline/test_switch_statement.csd <https://github.com/csound/csound/blob/040eb9a809f758775c63a9b6318958189ef0b83d/tests/commandline/test_switch_statement.csd> <https://github.com/csound/csound/blob/040eb9a809f758775c63a9b6318958189ef0b83d/tests/commandline/test_switch_statement.csd <https://github.com/csound/csound/blob/040eb9a809f758775c63a9b6318958189ef0b83d/tests/commandline/test_switch_statement.csd>>
>              >
>              > Before I went on xmas holiday I opened another similar PR
>             for for-of
>              > loops, you could test that my checking
>             out feature/for-of-iterator
>              > and test the feture with this commandline testfile
>              >
>             https://github.com/csound/csound/blob/7408361c69b806f675e21d08eff48341e6599273/tests/commandline/arrays/arrays_for_loop.csd <https://github.com/csound/csound/blob/7408361c69b806f675e21d08eff48341e6599273/tests/commandline/arrays/arrays_for_loop.csd> <https://github.com/csound/csound/blob/7408361c69b806f675e21d08eff48341e6599273/tests/commandline/arrays/arrays_for_loop.csd <https://github.com/csound/csound/blob/7408361c69b806f675e21d08eff48341e6599273/tests/commandline/arrays/arrays_for_loop.csd>>
>              >
>              > this for-of loop would only work for arrays, and would be
>             all in all
>              > exactly the same as you'd expect in javascript with
>             for-of loops there.
>              >
>              > The other PRs are mostly fixes and completion of new
>             features. But I'm
>              > eager to use the time over the holidays to learn C and
>             help with getting
>              > csound7 further.
>              >
>              >
>              > On Wed, 28 Dec 2022 at 21:26, joachim heintz
>             <jh@joachimheintz.de <mailto:jh@joachimheintz.de>
>              > <mailto:jh@joachimheintz.de
>             <mailto:jh@joachimheintz.de>>> wrote:
>              >
>              >     hi all -
>              >
>              >     i am so excited to see hlodver pushing a lot of stuff
>             to the cs7
>              >     branches (and some already on dhe develop branch).
>             i'd be curious to
>              >     check some things out: are there any descriptions or
>             tests from shich i
>              >     can learn what is new?
>              >
>              >     cheers -
>              >              joachim
>              >
>