Hi Anton,

Yes, the notation for arrays reflects an underlying change in Csound 6
with how variables are processed by the compiler.  For arrays, the
rule is that the first time they are assigned on the left-hand side of
an opcode, they need to have [] to denote the type of the variable.
For example:

kArr2[] = karr1 + 10
kArr2 = karr2 + 2

would work.  In Csound 6, the parser, when encountering a variable
name for the first time, figures out its type and enters it into a
table.  It uses the [] to figure out the var is an array-type.
Afterwards the variable name is used to lookup the type.  This
underlying change from previous Csound's was necessary foundation work
for what is allowed in Csound 7:

myvar:i = 1
myOtherVar:k = 4
kval = myOtherVal + myvar

and matches expectations from other programming languages, like C:

int myvar = 1;
int myOtherVar = 4;
myOtherVar = myvar + myOtherVar;

where the types are only designated upon their first use.

The explicit types above ties into user-defined datatypes and new UDO
syntax in CS7:

struct Rectangular x:i, y:i
struct Polar R:i, t:i

opcode to_polar(num:Rectangular):(Polar)
  ipolarR = sqrt(num.x ^ 2 + num.y ^ 2)
  ipolart = taninv2(num.y, num.x) * (360 / (2 * $M_PI))
  retVal:Polar init ipolarR, ipolart
  xout retVal
endop

instr 1
  r:Rectangular init 1.0, 0.5
  polar:Polar = to_polar(r)

  print polar.R ; 1.118
  print polar.t ; 26.565
endin


Hope that didn't stray too far from talking about array notation, but
I wanted to explain a bit of how that worked as I thought it might be
helpful.

steven




On Mon, Dec 12, 2016 at 4:25 AM, Anton Kholomiov
 wrote:
> I can not get the assignment to arrays for operations that work on arrays as
> a whole.
> Do you need to preallocte the output array? Or it's going to be created
> after
> the operation is completed.
>
> kDest[] arrayOperation kSrc[]
>
> Do you have to write [] only  for outputs but not for inputs?
> I saw the statements like this:
>
> kArr2[] = kArr1 + 10
>
> Anton
>
>
>
>
>
> Csound mailing list Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
> https://github.com/csound/csound/issues Discussions of bugs and features can
> be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

num here is the input argument to the to_polar opcode.  The
num:Rectangular uses the same explicit-type syntax for the opcode
input arguments as used for explicitly defining variable types within
code.

This remind me that I essentially have this all documented within my
PhD thesis, which might be a useful reference here.  I'll post a link
to that in a separate email.

On Mon, Dec 12, 2016 at 9:35 AM, Rory Walsh  wrote:
> Nice info there Steven. What's num for? I see you need to use it when
> passing struct to an opcode?
>
>
> Csound mailing list Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
> https://github.com/csound/csound/issues Discussions of bugs and features can
> be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Wow, this is great. Looking forward to 7. Thanks for all the work on
this, Steven (and Victor).


2016-12-12 6:40 GMT-08:00 Steven Yi :
> num here is the input argument to the to_polar opcode.  The
> num:Rectangular uses the same explicit-type syntax for the opcode
> input arguments as used for explicitly defining variable types within
> code.
>
> This remind me that I essentially have this all documented within my
> PhD thesis, which might be a useful reference here.  I'll post a link
> to that in a separate email.
>
> On Mon, Dec 12, 2016 at 9:35 AM, Rory Walsh  wrote:
>> Nice info there Steven. What's num for? I see you need to use it when
>> passing struct to an opcode?
>>
>>
>> Csound mailing list Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>> https://github.com/csound/csound/issues Discussions of bugs and features can
>> be posted here
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

I did a quick test and it looks like that actually works alright.  (I
was expecting a compilation error myself.)

I think that the parser code finds the "kArr2[]" and parses it as
"kArr2" with metadata the var is an array. The metadata would be used
on first-encounter with kArr2 and ignored if found again.  However,
this seems like a bug, as is demonstrable with the following code:




; ==============================================

sr = 48000
ksmps = 1
;nchnls = 2
0dbfs = 1
instr 1
karr[] fillarray 1,2,3,4
karr[] = karr + 4
kindx = 0
while kindx < 4 do
  printk2 karr[kindx]
  kindx += 1
od

endin

instr 2
karr init 1
karr[] = karr + 4
printk2 karr

endin

; ==============================================

i1 0 0.001
i2 0.1 0.001



The above operates, but it probably shouldn't. In instr 2, the karr[]
in the second line functions as just karr, which is defined first in
the line above it as a k-rate scalar value.  The second line is
misleading in instr2, and I would imagine it *should* be considered a
bug to redeclare a variable's type a second time for arrays (and
explicitly-typed vars in CS7).  This would be in-line with errors that
would be reported in C-like languages, such as:

int x = 4;
int x = 5;  // ERROR


I can see though what you mean about making arrays a little trickier
for you being context-dependent. If we can ever move on to the end
goal to have type inference, that problem would go away.  But for the
interim, I think this may be an issue not only for arrays but also for
user-defined types if you're using them from a wrapping language
(e.g., csound-expression). Besides type inference, I'm not sure I see
another way to address the issue, but perhaps someone else may see
something.



On Mon, Dec 12, 2016 at 11:12 AM, Anton Kholomiov
 wrote:
> But what if I write:
>
> kArr2[] = karr1 + 10
> kArr2[] = karr2 + 2
>
> How is it going to be interpreted by compiler?
>
> 2016-12-12 19:10 GMT+03:00 Anton Kholomiov :
>>
>> Thanks for explanation Steven, that makes things a bit more complicated
>> for me
>> as grammar becomes context dependent, but I hope I would figure out how to
>> handle
>> this case..
>>
>> 2016-12-12 19:07 GMT+03:00 Oeyvind Brandtsegg :
>>>
>>> Wow, this is great. Looking forward to 7. Thanks for all the work on
>>> this, Steven (and Victor).
>>>
>>>
>>> 2016-12-12 6:40 GMT-08:00 Steven Yi :
>>> > num here is the input argument to the to_polar opcode.  The
>>> > num:Rectangular uses the same explicit-type syntax for the opcode
>>> > input arguments as used for explicitly defining variable types within
>>> > code.
>>> >
>>> > This remind me that I essentially have this all documented within my
>>> > PhD thesis, which might be a useful reference here.  I'll post a link
>>> > to that in a separate email.
>>> >
>>> > On Mon, Dec 12, 2016 at 9:35 AM, Rory Walsh  wrote:
>>> >> Nice info there Steven. What's num for? I see you need to use it when
>>> >> passing struct to an opcode?
>>> >>
>>> >>
>>> >> Csound mailing list Csound@listserv.heanet.ie
>>> >> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>>> >> https://github.com/csound/csound/issues Discussions of bugs and
>>> >> features can
>>> >> be posted here
>>> >
>>> > Csound mailing list
>>> > Csound@listserv.heanet.ie
>>> > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> > Send bugs reports to
>>> >         https://github.com/csound/csound/issues
>>> > Discussions of bugs and features can be posted here
>>>
>>>
>>>
>>> --
>>>
>>> Oeyvind Brandtsegg
>>> Professor of Music Technology
>>> NTNU
>>> 7491 Trondheim
>>> Norway
>>> Cell: +47 92 203 205
>>>
>>> http://www.partikkelaudio.com/
>>> http://crossadaptive.hf.ntnu.no
>>> http://gdsp.hf.ntnu.no/
>>> http://soundcloud.com/brandtsegg
>>> http://flyndresang.no/
>>> http://soundcloud.com/t-emp
>>>
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>         https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>>
>>
>
> Csound mailing list Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
> https://github.com/csound/csound/issues Discussions of bugs and features can
> be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Hi Peter,

Csound 7 is not about to be released, but there has been work ongoing
towards it.  We have been tracking things for Csound 7 here:

https://github.com/csound/csound/milestone/12

Being a major version number change, CS7 has changes that are
backwards incompatible for its API as internal things are changing
(the Csound ORC and SCO language will be backwards compatible though).
We were talking about maybe moving primary development towards CS7 at
the Csound 30 conference, but the scheduling depends upon what comes
up for issues.

For CS7, I imagine once we shift to it, it will require some time to
finish implementing new features and doing testing to ensure backwards
compatibility for the langauge is preserved.  Documentation will also
take up time.  The plan is that once we move to CS7, CS6 will remain
in development within a separate branch of code, primarily for bug
fixes and smaller features that do not require internal/API-breaking
changes.  Any features introduced in CS6 while CS7 progresses will of
course be merged into CS7.

Hope that clears that up!
steven

On Mon, Dec 12, 2016 at 11:20 AM, Peter Burgess
 wrote:
> I'm clearly a bit behind here. Is Csound 7 about to be released then? I
> though t you'd just released 6.08. And what you guys are talking about here
> are changes coming up in Csound 7?
>
> On 12 Dec 2016 4:12 p.m., "Anton Kholomiov" 
> wrote:
>>
>> But what if I write:
>>
>> kArr2[] = karr1 + 10
>> kArr2[] = karr2 + 2
>>
>> How is it going to be interpreted by compiler?
>>
>> 2016-12-12 19:10 GMT+03:00 Anton Kholomiov :
>>>
>>> Thanks for explanation Steven, that makes things a bit more complicated
>>> for me
>>> as grammar becomes context dependent, but I hope I would figure out how
>>> to handle
>>> this case..
>>>
>>> 2016-12-12 19:07 GMT+03:00 Oeyvind Brandtsegg
>>> :
>>>>
>>>> Wow, this is great. Looking forward to 7. Thanks for all the work on
>>>> this, Steven (and Victor).
>>>>
>>>>
>>>> 2016-12-12 6:40 GMT-08:00 Steven Yi :
>>>> > num here is the input argument to the to_polar opcode.  The
>>>> > num:Rectangular uses the same explicit-type syntax for the opcode
>>>> > input arguments as used for explicitly defining variable types within
>>>> > code.
>>>> >
>>>> > This remind me that I essentially have this all documented within my
>>>> > PhD thesis, which might be a useful reference here.  I'll post a link
>>>> > to that in a separate email.
>>>> >
>>>> > On Mon, Dec 12, 2016 at 9:35 AM, Rory Walsh  wrote:
>>>> >> Nice info there Steven. What's num for? I see you need to use it when
>>>> >> passing struct to an opcode?
>>>> >>
>>>> >>
>>>> >> Csound mailing list Csound@listserv.heanet.ie
>>>> >> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>>>> >> https://github.com/csound/csound/issues Discussions of bugs and
>>>> >> features can
>>>> >> be posted here
>>>> >
>>>> > Csound mailing list
>>>> > Csound@listserv.heanet.ie
>>>> > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>> > Send bugs reports to
>>>> >         https://github.com/csound/csound/issues
>>>> > Discussions of bugs and features can be posted here
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Oeyvind Brandtsegg
>>>> Professor of Music Technology
>>>> NTNU
>>>> 7491 Trondheim
>>>> Norway
>>>> Cell: +47 92 203 205
>>>>
>>>> http://www.partikkelaudio.com/
>>>> http://crossadaptive.hf.ntnu.no
>>>> http://gdsp.hf.ntnu.no/
>>>> http://soundcloud.com/brandtsegg
>>>> http://flyndresang.no/
>>>> http://soundcloud.com/t-emp
>>>>
>>>> Csound mailing list
>>>> Csound@listserv.heanet.ie
>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>> Send bugs reports to
>>>>         https://github.com/csound/csound/issues
>>>> Discussions of bugs and features can be posted here
>>>
>>>
>>
>> Csound mailing list Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>> https://github.com/csound/csound/issues Discussions of bugs and features can
>> be posted here
>
> Csound mailing list Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
> https://github.com/csound/csound/issues Discussions of bugs and features can
> be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Yes, I think that sums it up.  As a sidenote, there was an issue I had
filed for CS7 but closed:

https://github.com/csound/csound/issues/447

but this might be a potential use case.  Do you think having a declare
option would be of use to you for this situation?

On Mon, Dec 12, 2016 at 11:41 AM, Anton Kholomiov
 wrote:
> Ok! It works right now, but I shouldn't rely on this behavior.
>
> 2016-12-12 19:34 GMT+03:00 Steven Yi :
>>
>> I did a quick test and it looks like that actually works alright.  (I
>> was expecting a compilation error myself.)
>>
>> I think that the parser code finds the "kArr2[]" and parses it as
>> "kArr2" with metadata the var is an array. The metadata would be used
>> on first-encounter with kArr2 and ignored if found again.  However,
>> this seems like a bug, as is demonstrable with the following code:
>>
>> 
>> 
>> 
>> ; ==============================================
>> 
>> sr = 48000
>> ksmps = 1
>> ;nchnls = 2
>> 0dbfs = 1
>> instr 1
>> karr[] fillarray 1,2,3,4
>> karr[] = karr + 4
>> kindx = 0
>> while kindx < 4 do
>>   printk2 karr[kindx]
>>   kindx += 1
>> od
>>
>> endin
>>
>> instr 2
>> karr init 1
>> karr[] = karr + 4
>> printk2 karr
>>
>> endin
>> 
>> ; ==============================================
>> 
>> i1 0 0.001
>> i2 0.1 0.001
>> 
>> 
>>
>> The above operates, but it probably shouldn't. In instr 2, the karr[]
>> in the second line functions as just karr, which is defined first in
>> the line above it as a k-rate scalar value.  The second line is
>> misleading in instr2, and I would imagine it *should* be considered a
>> bug to redeclare a variable's type a second time for arrays (and
>> explicitly-typed vars in CS7).  This would be in-line with errors that
>> would be reported in C-like languages, such as:
>>
>> int x = 4;
>> int x = 5;  // ERROR
>>
>>
>> I can see though what you mean about making arrays a little trickier
>> for you being context-dependent. If we can ever move on to the end
>> goal to have type inference, that problem would go away.  But for the
>> interim, I think this may be an issue not only for arrays but also for
>> user-defined types if you're using them from a wrapping language
>> (e.g., csound-expression). Besides type inference, I'm not sure I see
>> another way to address the issue, but perhaps someone else may see
>> something.
>>
>>
>>
>> On Mon, Dec 12, 2016 at 11:12 AM, Anton Kholomiov
>>  wrote:
>> > But what if I write:
>> >
>> > kArr2[] = karr1 + 10
>> > kArr2[] = karr2 + 2
>> >
>> > How is it going to be interpreted by compiler?
>> >
>> > 2016-12-12 19:10 GMT+03:00 Anton Kholomiov :
>> >>
>> >> Thanks for explanation Steven, that makes things a bit more complicated
>> >> for me
>> >> as grammar becomes context dependent, but I hope I would figure out how
>> >> to
>> >> handle
>> >> this case..
>> >>
>> >> 2016-12-12 19:07 GMT+03:00 Oeyvind Brandtsegg
>> >> :
>> >>>
>> >>> Wow, this is great. Looking forward to 7. Thanks for all the work on
>> >>> this, Steven (and Victor).
>> >>>
>> >>>
>> >>> 2016-12-12 6:40 GMT-08:00 Steven Yi :
>> >>> > num here is the input argument to the to_polar opcode.  The
>> >>> > num:Rectangular uses the same explicit-type syntax for the opcode
>> >>> > input arguments as used for explicitly defining variable types
>> >>> > within
>> >>> > code.
>> >>> >
>> >>> > This remind me that I essentially have this all documented within my
>> >>> > PhD thesis, which might be a useful reference here.  I'll post a
>> >>> > link
>> >>> > to that in a separate email.
>> >>> >
>> >>> > On Mon, Dec 12, 2016 at 9:35 AM, Rory Walsh 
>> >>> > wrote:
>> >>> >> Nice info there Steven. What's num for? I see you need to use it
>> >>> >> when
>> >>> >> passing struct to an opcode?
>> >>> >>
>> >>> >>
>> >>> >> Csound mailing list Csound@listserv.heanet.ie
>> >>> >> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports
>> >>> >> to
>> >>> >> https://github.com/csound/csound/issues Discussions of bugs and
>> >>> >> features can
>> >>> >> be posted here
>> >>> >
>> >>> > Csound mailing list
>> >>> > Csound@listserv.heanet.ie
>> >>> > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> >>> > Send bugs reports to
>> >>> >         https://github.com/csound/csound/issues
>> >>> > Discussions of bugs and features can be posted here
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>>
>> >>> Oeyvind Brandtsegg
>> >>> Professor of Music Technology
>> >>> NTNU
>> >>> 7491 Trondheim
>> >>> Norway
>> >>> Cell: +47 92 203 205
>> >>>
>> >>> http://www.partikkelaudio.com/
>> >>> http://crossadaptive.hf.ntnu.no
>> >>> http://gdsp.hf.ntnu.no/
>> >>> http://soundcloud.com/brandtsegg
>> >>> http://flyndresang.no/
>> >>> http://soundcloud.com/t-emp
>> >>>
>> >>> Csound mailing list
>> >>> Csound@listserv.heanet.ie
>> >>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> >>> Send bugs reports to
>> >>>         https://github.com/csound/csound/issues
>> >>> Discussions of bugs and features can be posted here
>> >>
>> >>
>> >
>> > Csound mailing list Csound@listserv.heanet.ie
>> > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>> > https://github.com/csound/csound/issues Discussions of bugs and features
>> > can
>> > be posted here
>>
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>         https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>
>
> Csound mailing list Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
> https://github.com/csound/csound/issues Discussions of bugs and features can
> be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Nice! I'm looking forward to what new things CS7 brings to the table
:D So is that available for download and testing already?

On Mon, Dec 12, 2016 at 5:15 PM, Steven Yi  wrote:
> Yes, I think that sums it up.  As a sidenote, there was an issue I had
> filed for CS7 but closed:
>
> https://github.com/csound/csound/issues/447
>
> but this might be a potential use case.  Do you think having a declare
> option would be of use to you for this situation?
>
> On Mon, Dec 12, 2016 at 11:41 AM, Anton Kholomiov
>  wrote:
>> Ok! It works right now, but I shouldn't rely on this behavior.
>>
>> 2016-12-12 19:34 GMT+03:00 Steven Yi :
>>>
>>> I did a quick test and it looks like that actually works alright.  (I
>>> was expecting a compilation error myself.)
>>>
>>> I think that the parser code finds the "kArr2[]" and parses it as
>>> "kArr2" with metadata the var is an array. The metadata would be used
>>> on first-encounter with kArr2 and ignored if found again.  However,
>>> this seems like a bug, as is demonstrable with the following code:
>>>
>>> 
>>> 
>>> 
>>> ; ==============================================
>>> 
>>> sr = 48000
>>> ksmps = 1
>>> ;nchnls = 2
>>> 0dbfs = 1
>>> instr 1
>>> karr[] fillarray 1,2,3,4
>>> karr[] = karr + 4
>>> kindx = 0
>>> while kindx < 4 do
>>>   printk2 karr[kindx]
>>>   kindx += 1
>>> od
>>>
>>> endin
>>>
>>> instr 2
>>> karr init 1
>>> karr[] = karr + 4
>>> printk2 karr
>>>
>>> endin
>>> 
>>> ; ==============================================
>>> 
>>> i1 0 0.001
>>> i2 0.1 0.001
>>> 
>>> 
>>>
>>> The above operates, but it probably shouldn't. In instr 2, the karr[]
>>> in the second line functions as just karr, which is defined first in
>>> the line above it as a k-rate scalar value.  The second line is
>>> misleading in instr2, and I would imagine it *should* be considered a
>>> bug to redeclare a variable's type a second time for arrays (and
>>> explicitly-typed vars in CS7).  This would be in-line with errors that
>>> would be reported in C-like languages, such as:
>>>
>>> int x = 4;
>>> int x = 5;  // ERROR
>>>
>>>
>>> I can see though what you mean about making arrays a little trickier
>>> for you being context-dependent. If we can ever move on to the end
>>> goal to have type inference, that problem would go away.  But for the
>>> interim, I think this may be an issue not only for arrays but also for
>>> user-defined types if you're using them from a wrapping language
>>> (e.g., csound-expression). Besides type inference, I'm not sure I see
>>> another way to address the issue, but perhaps someone else may see
>>> something.
>>>
>>>
>>>
>>> On Mon, Dec 12, 2016 at 11:12 AM, Anton Kholomiov
>>>  wrote:
>>> > But what if I write:
>>> >
>>> > kArr2[] = karr1 + 10
>>> > kArr2[] = karr2 + 2
>>> >
>>> > How is it going to be interpreted by compiler?
>>> >
>>> > 2016-12-12 19:10 GMT+03:00 Anton Kholomiov :
>>> >>
>>> >> Thanks for explanation Steven, that makes things a bit more complicated
>>> >> for me
>>> >> as grammar becomes context dependent, but I hope I would figure out how
>>> >> to
>>> >> handle
>>> >> this case..
>>> >>
>>> >> 2016-12-12 19:07 GMT+03:00 Oeyvind Brandtsegg
>>> >> :
>>> >>>
>>> >>> Wow, this is great. Looking forward to 7. Thanks for all the work on
>>> >>> this, Steven (and Victor).
>>> >>>
>>> >>>
>>> >>> 2016-12-12 6:40 GMT-08:00 Steven Yi :
>>> >>> > num here is the input argument to the to_polar opcode.  The
>>> >>> > num:Rectangular uses the same explicit-type syntax for the opcode
>>> >>> > input arguments as used for explicitly defining variable types
>>> >>> > within
>>> >>> > code.
>>> >>> >
>>> >>> > This remind me that I essentially have this all documented within my
>>> >>> > PhD thesis, which might be a useful reference here.  I'll post a
>>> >>> > link
>>> >>> > to that in a separate email.
>>> >>> >
>>> >>> > On Mon, Dec 12, 2016 at 9:35 AM, Rory Walsh 
>>> >>> > wrote:
>>> >>> >> Nice info there Steven. What's num for? I see you need to use it
>>> >>> >> when
>>> >>> >> passing struct to an opcode?
>>> >>> >>
>>> >>> >>
>>> >>> >> Csound mailing list Csound@listserv.heanet.ie
>>> >>> >> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports
>>> >>> >> to
>>> >>> >> https://github.com/csound/csound/issues Discussions of bugs and
>>> >>> >> features can
>>> >>> >> be posted here
>>> >>> >
>>> >>> > Csound mailing list
>>> >>> > Csound@listserv.heanet.ie
>>> >>> > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> >>> > Send bugs reports to
>>> >>> >         https://github.com/csound/csound/issues
>>> >>> > Discussions of bugs and features can be posted here
>>> >>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>>
>>> >>> Oeyvind Brandtsegg
>>> >>> Professor of Music Technology
>>> >>> NTNU
>>> >>> 7491 Trondheim
>>> >>> Norway
>>> >>> Cell: +47 92 203 205
>>> >>>
>>> >>> http://www.partikkelaudio.com/
>>> >>> http://crossadaptive.hf.ntnu.no
>>> >>> http://gdsp.hf.ntnu.no/
>>> >>> http://soundcloud.com/brandtsegg
>>> >>> http://flyndresang.no/
>>> >>> http://soundcloud.com/t-emp
>>> >>>
>>> >>> Csound mailing list
>>> >>> Csound@listserv.heanet.ie
>>> >>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> >>> Send bugs reports to
>>> >>>         https://github.com/csound/csound/issues
>>> >>> Discussions of bugs and features can be posted here
>>> >>
>>> >>
>>> >
>>> > Csound mailing list Csound@listserv.heanet.ie
>>> > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>>> > https://github.com/csound/csound/issues Discussions of bugs and features
>>> > can
>>> > be posted here
>>>
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>         https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>>
>>
>> Csound mailing list Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>> https://github.com/csound/csound/issues Discussions of bugs and features can
>> be posted here
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

yes i expected an error, too, and i think you explained clearly why it 
should.

	joachim


On 12/12/16 17:34, Steven Yi wrote:
> I did a quick test and it looks like that actually works alright.  (I
> was expecting a compilation error myself.)
>
> I think that the parser code finds the "kArr2[]" and parses it as
> "kArr2" with metadata the var is an array. The metadata would be used
> on first-encounter with kArr2 and ignored if found again.  However,
> this seems like a bug, as is demonstrable with the following code:
>
> 
> 
> 
> ; ==============================================
> 
> sr = 48000
> ksmps = 1
> ;nchnls = 2
> 0dbfs = 1
> instr 1
> karr[] fillarray 1,2,3,4
> karr[] = karr + 4
> kindx = 0
> while kindx < 4 do
>   printk2 karr[kindx]
>   kindx += 1
> od
>
> endin
>
> instr 2
> karr init 1
> karr[] = karr + 4
> printk2 karr
>
> endin
> 
> ; ==============================================
> 
> i1 0 0.001
> i2 0.1 0.001
> 
> 
>
> The above operates, but it probably shouldn't. In instr 2, the karr[]
> in the second line functions as just karr, which is defined first in
> the line above it as a k-rate scalar value.  The second line is
> misleading in instr2, and I would imagine it *should* be considered a
> bug to redeclare a variable's type a second time for arrays (and
> explicitly-typed vars in CS7).  This would be in-line with errors that
> would be reported in C-like languages, such as:
>
> int x = 4;
> int x = 5;  // ERROR
>
>
> I can see though what you mean about making arrays a little trickier
> for you being context-dependent. If we can ever move on to the end
> goal to have type inference, that problem would go away.  But for the
> interim, I think this may be an issue not only for arrays but also for
> user-defined types if you're using them from a wrapping language
> (e.g., csound-expression). Besides type inference, I'm not sure I see
> another way to address the issue, but perhaps someone else may see
> something.
>
>
>
> On Mon, Dec 12, 2016 at 11:12 AM, Anton Kholomiov
>  wrote:
>> But what if I write:
>>
>> kArr2[] = karr1 + 10
>> kArr2[] = karr2 + 2
>>
>> How is it going to be interpreted by compiler?
>>
>> 2016-12-12 19:10 GMT+03:00 Anton Kholomiov :
>>>
>>> Thanks for explanation Steven, that makes things a bit more complicated
>>> for me
>>> as grammar becomes context dependent, but I hope I would figure out how to
>>> handle
>>> this case..
>>>
>>> 2016-12-12 19:07 GMT+03:00 Oeyvind Brandtsegg :
>>>>
>>>> Wow, this is great. Looking forward to 7. Thanks for all the work on
>>>> this, Steven (and Victor).
>>>>
>>>>
>>>> 2016-12-12 6:40 GMT-08:00 Steven Yi :
>>>>> num here is the input argument to the to_polar opcode.  The
>>>>> num:Rectangular uses the same explicit-type syntax for the opcode
>>>>> input arguments as used for explicitly defining variable types within
>>>>> code.
>>>>>
>>>>> This remind me that I essentially have this all documented within my
>>>>> PhD thesis, which might be a useful reference here.  I'll post a link
>>>>> to that in a separate email.
>>>>>
>>>>> On Mon, Dec 12, 2016 at 9:35 AM, Rory Walsh  wrote:
>>>>>> Nice info there Steven. What's num for? I see you need to use it when
>>>>>> passing struct to an opcode?
>>>>>>
>>>>>>
>>>>>> Csound mailing list Csound@listserv.heanet.ie
>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>>>>>> https://github.com/csound/csound/issues Discussions of bugs and
>>>>>> features can
>>>>>> be posted here
>>>>>
>>>>> Csound mailing list
>>>>> Csound@listserv.heanet.ie
>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>> Send bugs reports to
>>>>>         https://github.com/csound/csound/issues
>>>>> Discussions of bugs and features can be posted here
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Oeyvind Brandtsegg
>>>> Professor of Music Technology
>>>> NTNU
>>>> 7491 Trondheim
>>>> Norway
>>>> Cell: +47 92 203 205
>>>>
>>>> http://www.partikkelaudio.com/
>>>> http://crossadaptive.hf.ntnu.no
>>>> http://gdsp.hf.ntnu.no/
>>>> http://soundcloud.com/brandtsegg
>>>> http://flyndresang.no/
>>>> http://soundcloud.com/t-emp
>>>>
>>>> Csound mailing list
>>>> Csound@listserv.heanet.ie
>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>> Send bugs reports to
>>>>         https://github.com/csound/csound/issues
>>>> Discussions of bugs and features can be posted here
>>>
>>>
>>
>> Csound mailing list Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>> https://github.com/csound/csound/issues Discussions of bugs and features can
>> be posted here
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I've filed issue #728 to track this:

https://github.com/csound/csound/issues/728

and have assigned it to the 6.x milestone so that it will be done for CS6.


On Mon, Dec 12, 2016 at 3:29 PM, joachim heintz  wrote:
> yes i expected an error, too, and i think you explained clearly why it
> should.
>
>         joachim
>
>
>
> On 12/12/16 17:34, Steven Yi wrote:
>>
>> I did a quick test and it looks like that actually works alright.  (I
>> was expecting a compilation error myself.)
>>
>> I think that the parser code finds the "kArr2[]" and parses it as
>> "kArr2" with metadata the var is an array. The metadata would be used
>> on first-encounter with kArr2 and ignored if found again.  However,
>> this seems like a bug, as is demonstrable with the following code:
>>
>> 
>> 
>> 
>> ; ==============================================
>> 
>> sr = 48000
>> ksmps = 1
>> ;nchnls = 2
>> 0dbfs = 1
>> instr 1
>> karr[] fillarray 1,2,3,4
>> karr[] = karr + 4
>> kindx = 0
>> while kindx < 4 do
>>   printk2 karr[kindx]
>>   kindx += 1
>> od
>>
>> endin
>>
>> instr 2
>> karr init 1
>> karr[] = karr + 4
>> printk2 karr
>>
>> endin
>> 
>> ; ==============================================
>> 
>> i1 0 0.001
>> i2 0.1 0.001
>> 
>> 
>>
>> The above operates, but it probably shouldn't. In instr 2, the karr[]
>> in the second line functions as just karr, which is defined first in
>> the line above it as a k-rate scalar value.  The second line is
>> misleading in instr2, and I would imagine it *should* be considered a
>> bug to redeclare a variable's type a second time for arrays (and
>> explicitly-typed vars in CS7).  This would be in-line with errors that
>> would be reported in C-like languages, such as:
>>
>> int x = 4;
>> int x = 5;  // ERROR
>>
>>
>> I can see though what you mean about making arrays a little trickier
>> for you being context-dependent. If we can ever move on to the end
>> goal to have type inference, that problem would go away.  But for the
>> interim, I think this may be an issue not only for arrays but also for
>> user-defined types if you're using them from a wrapping language
>> (e.g., csound-expression). Besides type inference, I'm not sure I see
>> another way to address the issue, but perhaps someone else may see
>> something.
>>
>>
>>
>> On Mon, Dec 12, 2016 at 11:12 AM, Anton Kholomiov
>>  wrote:
>>>
>>> But what if I write:
>>>
>>> kArr2[] = karr1 + 10
>>> kArr2[] = karr2 + 2
>>>
>>> How is it going to be interpreted by compiler?
>>>
>>> 2016-12-12 19:10 GMT+03:00 Anton Kholomiov :
>>>>
>>>>
>>>> Thanks for explanation Steven, that makes things a bit more complicated
>>>> for me
>>>> as grammar becomes context dependent, but I hope I would figure out how
>>>> to
>>>> handle
>>>> this case..
>>>>
>>>> 2016-12-12 19:07 GMT+03:00 Oeyvind Brandtsegg
>>>> :
>>>>>
>>>>>
>>>>> Wow, this is great. Looking forward to 7. Thanks for all the work on
>>>>> this, Steven (and Victor).
>>>>>
>>>>>
>>>>> 2016-12-12 6:40 GMT-08:00 Steven Yi :
>>>>>>
>>>>>> num here is the input argument to the to_polar opcode.  The
>>>>>> num:Rectangular uses the same explicit-type syntax for the opcode
>>>>>> input arguments as used for explicitly defining variable types within
>>>>>> code.
>>>>>>
>>>>>> This remind me that I essentially have this all documented within my
>>>>>> PhD thesis, which might be a useful reference here.  I'll post a link
>>>>>> to that in a separate email.
>>>>>>
>>>>>> On Mon, Dec 12, 2016 at 9:35 AM, Rory Walsh  wrote:
>>>>>>>
>>>>>>> Nice info there Steven. What's num for? I see you need to use it when
>>>>>>> passing struct to an opcode?
>>>>>>>
>>>>>>>
>>>>>>> Csound mailing list Csound@listserv.heanet.ie
>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>>>>>>> https://github.com/csound/csound/issues Discussions of bugs and
>>>>>>> features can
>>>>>>> be posted here
>>>>>>
>>>>>>
>>>>>> Csound mailing list
>>>>>> Csound@listserv.heanet.ie
>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>> Send bugs reports to
>>>>>>         https://github.com/csound/csound/issues
>>>>>> Discussions of bugs and features can be posted here
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Oeyvind Brandtsegg
>>>>> Professor of Music Technology
>>>>> NTNU
>>>>> 7491 Trondheim
>>>>> Norway
>>>>> Cell: +47 92 203 205
>>>>>
>>>>> http://www.partikkelaudio.com/
>>>>> http://crossadaptive.hf.ntnu.no
>>>>> http://gdsp.hf.ntnu.no/
>>>>> http://soundcloud.com/brandtsegg
>>>>> http://flyndresang.no/
>>>>> http://soundcloud.com/t-emp
>>>>>
>>>>> Csound mailing list
>>>>> Csound@listserv.heanet.ie
>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>> Send bugs reports to
>>>>>         https://github.com/csound/csound/issues
>>>>> Discussions of bugs and features can be posted here
>>>>
>>>>
>>>>
>>>
>>> Csound mailing list Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>>> https://github.com/csound/csound/issues Discussions of bugs and features
>>> can
>>> be posted here
>>
>>
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>         https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>>
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here