i am going on with some manual examples for the array opcodes. some 
questions related to maxtab:

1) it looks like maxtab does not accept the array notation (like kArr[]) 
at all. when i run the example below, i get this error message:
error: syntax error, unexpected ']'  (token "]") line 20:
 >>>kMax       maxtab     kArr[] <<<
so perhaps i misunderstood that the tab opcodes can be used for the new 
arrays, too?

2) tarmo suggested that the maxtab/mintab opcodes would return the 
position of the element being found, too. i think this would indeed be 
very useful. could the opcode be extended to this form:
kmax [,kpos] maxtab tab
?

3) if also for arrays (or even for tables): could there be an 
init-version, too?

best -

	joachim




; Select audio/midi flags here according to platform
-n



            seed       0

instr 1
;create an array with 10 elements
kArr[]     init       10
;fill in random numbers and print them out
kndx       =          0
            until      kndx == 10 do
kNum       random     -100, 100
kArr[kndx] =          kNum
            printf     "kArr[%d] = %f\n", kndx+1, kndx, kNum
kndx       +=         1
od
;investigate maximum number and print it out
kMax       maxtab     kArr[]
            printf     "Maximum of kArr[] = %f\n", kndx+1, kMax
            turnoff
endin


i1 0 0.1
e



------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Joachim,

Array vars when used as arguments to opcodes should be just the
variable name without [].  For example:

kMax       maxtab     kArr

The use of [] after a variable name is only used to define/init an array var.

Hope that helps!
steven

On Wed, May 1, 2013 at 6:31 PM, joachim heintz  wrote:
> i am going on with some manual examples for the array opcodes. some
> questions related to maxtab:
>
> 1) it looks like maxtab does not accept the array notation (like kArr[])
> at all. when i run the example below, i get this error message:
> error: syntax error, unexpected ']'  (token "]") line 20:
>  >>>kMax       maxtab     kArr[] <<<
> so perhaps i misunderstood that the tab opcodes can be used for the new
> arrays, too?
>
> 2) tarmo suggested that the maxtab/mintab opcodes would return the
> position of the element being found, too. i think this would indeed be
> very useful. could the opcode be extended to this form:
> kmax [,kpos] maxtab tab
> ?
>
> 3) if also for arrays (or even for tables): could there be an
> init-version, too?
>
> best -
>
>         joachim
>
>
> 
> 
> ; Select audio/midi flags here according to platform
> -n
> 
> 
>
>             seed       0
>
> instr 1
> ;create an array with 10 elements
> kArr[]     init       10
> ;fill in random numbers and print them out
> kndx       =          0
>             until      kndx == 10 do
> kNum       random     -100, 100
> kArr[kndx] =          kNum
>             printf     "kArr[%d] = %f\n", kndx+1, kndx, kNum
> kndx       +=         1
> od
> ;investigate maximum number and print it out
> kMax       maxtab     kArr[]
>             printf     "Maximum of kArr[] = %f\n", kndx+1, kMax
>             turnoff
> endin
> 
> 
> i1 0 0.1
> e
> 
> 
>
> ------------------------------------------------------------------------------
> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
> Get 100% visibility into your production application - at no cost.
> Code-level diagnostics for performance bottlenecks with <2% overhead
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap1
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

hi steven -

thanks! as andrés mentioned, it might be more consistent to have the 
var[] notation in general for array variables. would it be difficult to 
allow both:
kMax       maxtab     kArr
AND
kMax       maxtab     kArr[]
?

best -

	joachim


Am 01.05.2013 22:58, schrieb Steven Yi:
> Hi Joachim,
>
> Array vars when used as arguments to opcodes should be just the
> variable name without [].  For example:
>
> kMax       maxtab     kArr
>
> The use of [] after a variable name is only used to define/init an array var.
>
> Hope that helps!
> steven
>
> On Wed, May 1, 2013 at 6:31 PM, joachim heintz  wrote:
>> i am going on with some manual examples for the array opcodes. some
>> questions related to maxtab:
>>
>> 1) it looks like maxtab does not accept the array notation (like kArr[])
>> at all. when i run the example below, i get this error message:
>> error: syntax error, unexpected ']'  (token "]") line 20:
>>   >>>kMax       maxtab     kArr[] <<<
>> so perhaps i misunderstood that the tab opcodes can be used for the new
>> arrays, too?
>>
>> 2) tarmo suggested that the maxtab/mintab opcodes would return the
>> position of the element being found, too. i think this would indeed be
>> very useful. could the opcode be extended to this form:
>> kmax [,kpos] maxtab tab
>> ?
>>
>> 3) if also for arrays (or even for tables): could there be an
>> init-version, too?
>>
>> best -
>>
>>          joachim
>>
>>
>> 
>> 
>> ; Select audio/midi flags here according to platform
>> -n
>> 
>> 
>>
>>              seed       0
>>
>> instr 1
>> ;create an array with 10 elements
>> kArr[]     init       10
>> ;fill in random numbers and print them out
>> kndx       =          0
>>              until      kndx == 10 do
>> kNum       random     -100, 100
>> kArr[kndx] =          kNum
>>              printf     "kArr[%d] = %f\n", kndx+1, kndx, kNum
>> kndx       +=         1
>> od
>> ;investigate maximum number and print it out
>> kMax       maxtab     kArr[]
>>              printf     "Maximum of kArr[] = %f\n", kndx+1, kMax
>>              turnoff
>> endin
>> 
>> 
>> i1 0 0.1
>> e
>> 
>> 
>>
>> ------------------------------------------------------------------------------
>> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
>> Get 100% visibility into your production application - at no cost.
>> Code-level diagnostics for performance bottlenecks with <2% overhead
>> Download for free and get started troubleshooting in minutes.
>> http://p.sf.net/sfu/appdyn_d2d_ap1
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
> Get 100% visibility into your production application - at no cost.
> Code-level diagnostics for performance bottlenecks with <2% overhead
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap1
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/li

Hi Joachim and Andres,

I think allowing both would be difficult, and might be a mistake to
have multiple options (becomes a parser/semantic issue, also becomes a
pedagogical issue to explain why it works two different ways).

Also, the idea of the declaring of type for a var and using the var
are sort of mixed in Csound.  In most other languages though, this
isn't the case. Types are inferred, or declared but not necessarily
part of the name.  For either, let's consider precedents in other
languages.  Something like C/C++/Java would have:

float myVals[128];
doSomething(myVals);  // void doSomething(float[] inarg);

Python has lists:

a = []
doSomething(a)

(blanking here, does python have arrays?)

Ruby has something similar:

a = []
doSomething(a)

all of these languages use a post-fix operator for array access, i.e.:

a[5] = 4
x = a[1] + a[2]

I think most of the functional languages deal with lists rather than
arrays, and end up using array accessing functions rather than
post-fix operators.  The ones I can think of at the moment (Haskell,
Clojure, Common Lisp, Scheme, OCaml) don't really use array [] syntax
for creating and accessing items, and don't add something like [] to
the variable's name itself.

For domain specific music languages, SAOL [1] and Supercollider [2]
also don't associate the type with the var name.

Now, in Csound, through now we have had this mandatory semantic
requirement where var names have their type encoded within their names
(i.e. first letter denotes type).  With Csound 6, we don't necessarily
have to make this a requirement anymore in its current form.  We can
imagine arrays as a first demonstration of this, but that it also
leaves room for further typing possbilities, such as:

data MyAmbisonicsType kx, ky, kz, kw

myVar:MyAmbisonicsType init 0, 0, 0, 0

asig myAmbiUdo myVar, .5, .5

Something like this would allow user-defined types, but extends what
is going on with arrays as they are now, where first declaration of
var has type declared, and future uses only require the name.

So, to sum up, I see two big reasons to go without requiring [] as
part of an array's name:

1) Other languages I'm aware of do it that way, and so this should be
easier to learn for those coming from other languages
2) Semantically this convention should allow for Csound language
growth to work with future type work, which would include type
inference and dynamic typing amongst other things.

If I've gotten anything wrong above, please let me know, as it's been
a long day here for me. :P

Thanks!
steven


[1] - http://www.cs.berkeley.edu/~lazzaro/sa/book/saol/exstat/index.html#array
[2] - http://danielnouri.org/docs/SuperColliderHelp/Collections/Array.html




On Thu, May 2, 2013 at 12:58 PM, joachim heintz  wrote:
> hi steven -
>
> thanks! as andrés mentioned, it might be more consistent to have the
> var[] notation in general for array variables. would it be difficult to
> allow both:
> kMax       maxtab     kArr
> AND
> kMax       maxtab     kArr[]
> ?
>
> best -
>
>         joachim
>
>
> Am 01.05.2013 22:58, schrieb Steven Yi:
>> Hi Joachim,
>>
>> Array vars when used as arguments to opcodes should be just the
>> variable name without [].  For example:
>>
>> kMax       maxtab     kArr
>>
>> The use of [] after a variable name is only used to define/init an array var.
>>
>> Hope that helps!
>> steven
>>
>> On Wed, May 1, 2013 at 6:31 PM, joachim heintz  wrote:
>>> i am going on with some manual examples for the array opcodes. some
>>> questions related to maxtab:
>>>
>>> 1) it looks like maxtab does not accept the array notation (like kArr[])
>>> at all. when i run the example below, i get this error message:
>>> error: syntax error, unexpected ']'  (token "]") line 20:
>>>   >>>kMax       maxtab     kArr[] <<<
>>> so perhaps i misunderstood that the tab opcodes can be used for the new
>>> arrays, too?
>>>
>>> 2) tarmo suggested that the maxtab/mintab opcodes would return the
>>> position of the element being found, too. i think this would indeed be
>>> very useful. could the opcode be extended to this form:
>>> kmax [,kpos] maxtab tab
>>> ?
>>>
>>> 3) if also for arrays (or even for tables): could there be an
>>> init-version, too?
>>>
>>> best -
>>>
>>>          joachim
>>>
>>>
>>> 
>>> 
>>> ; Select audio/midi flags here according to platform
>>> -n
>>> 
>>> 
>>>
>>>              seed       0
>>>
>>> instr 1
>>> ;create an array with 10 elements
>>> kArr[]     init       10
>>> ;fill in random numbers and print them out
>>> kndx       =          0
>>>              until      kndx == 10 do
>>> kNum       random     -100, 100
>>> kArr[kndx] =          kNum
>>>              printf     "kArr[%d] = %f\n", kndx+1, kndx, kNum
>>> kndx       +=         1
>>> od
>>> ;investigate maximum number and print it out
>>> kMax       maxtab     kArr[]
>>>              printf     "Maximum of kArr[] = %f\n", kndx+1, kMax
>>>              turnoff
>>> endin
>>> 
>>> 
>>> i1 0 0.1
>>> e
>>> 
>>> 
>>>
>>> ------------------------------------------------------------------------------
>>> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
>>> Get 100% visibility into your production application - at no cost.
>>> Code-level diagnostics for performance bottlenecks with <2% overhead
>>> Download for free and get started troubleshooting in minutes.
>>> http://p.sf.net/sfu/appdyn_d2d_ap1
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
>> Get 100% visibility into your production application - at no cost.
>> Code-level diagnostics for performance bottlenecks with <2% overhead
>> Download for free and get started troubleshooting in minutes.
>> http://p.sf.net/sfu/appdyn_d2d_ap1
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
> ------------------------------------------------------------------------------
> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
> Get 100% visibility into your production application - at no cost.
> Code-level diagnostics for performance bottlenecks with <2% overhead
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap1
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

hi steven -

thanks for this thorough answer! i am totally pro the flexibility of 
variable names. (and what you write about the possibility to release the 
mandatory i-,k- etc declaration is very exciting!!)

i think the problems is because at the initialization of an array the [] 
is required. whilst in python the variable name for a list is for 
instance bla, in csound the array name is kbla, but at initialization it 
is kbla[]. i understand that it is not possible to write
kArr init 5
because the parser needs to know that the variable is not meant as a 
number which is set to 5, but as an array which is set to length 5.

so, yes, i think too that it is for now the best solution to use kArr[] 
at initialization because it has to be, but to write kArr anyway.

in this logic: would it not be better if we used the pure variable name 
for the fill opcode, too? now it is:
kArr[] fill 1,-7.12345, sqrt(2)
but perhaps better:
kArr fill 1,-7.12345, sqrt(2)
?

best -
	joachim


Am 03.05.2013 00:25, schrieb Steven Yi:
> Hi Joachim and Andres,
>
> I think allowing both would be difficult, and might be a mistake to
> have multiple options (becomes a parser/semantic issue, also becomes a
> pedagogical issue to explain why it works two different ways).
>
> Also, the idea of the declaring of type for a var and using the var
> are sort of mixed in Csound.  In most other languages though, this
> isn't the case. Types are inferred, or declared but not necessarily
> part of the name.  For either, let's consider precedents in other
> languages.  Something like C/C++/Java would have:
>
> float myVals[128];
> doSomething(myVals);  // void doSomething(float[] inarg);
>
> Python has lists:
>
> a = []
> doSomething(a)
>
> (blanking here, does python have arrays?)
>
> Ruby has something similar:
>
> a = []
> doSomething(a)
>
> all of these languages use a post-fix operator for array access, i.e.:
>
> a[5] = 4
> x = a[1] + a[2]
>
> I think most of the functional languages deal with lists rather than
> arrays, and end up using array accessing functions rather than
> post-fix operators.  The ones I can think of at the moment (Haskell,
> Clojure, Common Lisp, Scheme, OCaml) don't really use array [] syntax
> for creating and accessing items, and don't add something like [] to
> the variable's name itself.
>
> For domain specific music languages, SAOL [1] and Supercollider [2]
> also don't associate the type with the var name.
>
> Now, in Csound, through now we have had this mandatory semantic
> requirement where var names have their type encoded within their names
> (i.e. first letter denotes type).  With Csound 6, we don't necessarily
> have to make this a requirement anymore in its current form.  We can
> imagine arrays as a first demonstration of this, but that it also
> leaves room for further typing possbilities, such as:
>
> data MyAmbisonicsType kx, ky, kz, kw
>
> myVar:MyAmbisonicsType init 0, 0, 0, 0
>
> asig myAmbiUdo myVar, .5, .5
>
> Something like this would allow user-defined types, but extends what
> is going on with arrays as they are now, where first declaration of
> var has type declared, and future uses only require the name.
>
> So, to sum up, I see two big reasons to go without requiring [] as
> part of an array's name:
>
> 1) Other languages I'm aware of do it that way, and so this should be
> easier to learn for those coming from other languages
> 2) Semantically this convention should allow for Csound language
> growth to work with future type work, which would include type
> inference and dynamic typing amongst other things.
>
> If I've gotten anything wrong above, please let me know, as it's been
> a long day here for me. :P
>
> Thanks!
> steven
>
>
> [1] - http://www.cs.berkeley.edu/~lazzaro/sa/book/saol/exstat/index.html#array
> [2] - http://danielnouri.org/docs/SuperColliderHelp/Collections/Array.html
>
>
>
>
> On Thu, May 2, 2013 at 12:58 PM, joachim heintz  wrote:
>> hi steven -
>>
>> thanks! as andrés mentioned, it might be more consistent to have the
>> var[] notation in general for array variables. would it be difficult to
>> allow both:
>> kMax       maxtab     kArr
>> AND
>> kMax       maxtab     kArr[]
>> ?
>>
>> best -
>>
>>          joachim
>>
>>
>> Am 01.05.2013 22:58, schrieb Steven Yi:
>>> Hi Joachim,
>>>
>>> Array vars when used as arguments to opcodes should be just the
>>> variable name without [].  For example:
>>>
>>> kMax       maxtab     kArr
>>>
>>> The use of [] after a variable name is only used to define/init an array var.
>>>
>>> Hope that helps!
>>> steven
>>>
>>> On Wed, May 1, 2013 at 6:31 PM, joachim heintz  wrote:
>>>> i am going on with some manual examples for the array opcodes. some
>>>> questions related to maxtab:
>>>>
>>>> 1) it looks like maxtab does not accept the array notation (like kArr[])
>>>> at all. when i run the example below, i get this error message:
>>>> error: syntax error, unexpected ']'  (token "]") line 20:
>>>>    >>>kMax       maxtab     kArr[] <<<
>>>> so perhaps i misunderstood that the tab opcodes can be used for the new
>>>> arrays, too?
>>>>
>>>> 2) tarmo suggested that the maxtab/mintab opcodes would return the
>>>> position of the element being found, too. i think this would indeed be
>>>> very useful. could the opcode be extended to this form:
>>>> kmax [,kpos] maxtab tab
>>>> ?
>>>>
>>>> 3) if also for arrays (or even for tables): could there be an
>>>> init-version, too?
>>>>
>>>> best -
>>>>
>>>>           joachim
>>>>
>>>>
>>>> 
>>>> 
>>>> ; Select audio/midi flags here according to platform
>>>> -n
>>>> 
>>>> 
>>>>
>>>>               seed       0
>>>>
>>>> instr 1
>>>> ;create an array with 10 elements
>>>> kArr[]     init       10
>>>> ;fill in random numbers and print them out
>>>> kndx       =          0
>>>>               until      kndx == 10 do
>>>> kNum       random     -100, 100
>>>> kArr[kndx] =          kNum
>>>>               printf     "kArr[%d] = %f\n", kndx+1, kndx, kNum
>>>> kndx       +=         1
>>>> od
>>>> ;investigate maximum number and print it out
>>>> kMax       maxtab     kArr[]
>>>>               printf     "Maximum of kArr[] = %f\n", kndx+1, kMax
>>>>               turnoff
>>>> endin
>>>> 
>>>> 
>>>> i1 0 0.1
>>>> e
>>>> 
>>>> 
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
>>>> Get 100% visibility into your production application - at no cost.
>>>> Code-level diagnostics for performance bottlenecks with <2% overhead
>>>> Download for free and get started troubleshooting in minutes.
>>>> http://p.sf.net/sfu/appdyn_d2d_ap1
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>> ------------------------------------------------------------------------------
>>> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
>>> Get 100% visibility into your production application - at no cost.
>>> Code-level diagnostics for performance bottlenecks with <2% overhead
>>> Download for free and get started troubleshooting in minutes.
>>> http://p.sf.net/sfu/appdyn_d2d_ap1
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>> ------------------------------------------------------------------------------
>> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
>> Get 100% visibility into your production application - at no cost.
>> Code-level diagnostics for performance bottlenecks with <2% overhead
>> Download for free and get started troubleshooting in minutes.
>> http://p.sf.net/sfu/appdyn_d2d_ap1
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.n

>> 2) tarmo suggested that the maxtab/mintab opcodes would return the
>> position of the element being found, too. i think this would indeed be
>> very useful. could the opcode be extended to this form: kmax [,kpos]
>> maxtab tab

I have written the code and committed but not tested.  

>> 3) if also for arrays (or even for tables): could there be an
>> init-version, too? 

Written, untested; maxtab, maxarray, min..., sum,,,

Not looked at string arrays yet

==John ffitch

------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Joachim,

Thanks for the thoughtful points; I think it highlights some of the
tricky areas we need to figure out in guiding the evolution of the
language.  Regarding fillarray, the left-hand side (LHS) is using
kArr[] for a newly declared array.  However, it should be possible to
do:

kArr[] init 3
kArr fillarray 1,-7.12345, sqrt(2)

By the time the 2nd line is evaluated, the first line has already
declared and initialized "kArr" as an array of k-vals.

Thanks!
steven

On Fri, May 3, 2013 at 9:23 PM, joachim heintz  wrote:
> hi steven -
>
> thanks for this thorough answer! i am totally pro the flexibility of
> variable names. (and what you write about the possibility to release the
> mandatory i-,k- etc declaration is very exciting!!)
>
> i think the problems is because at the initialization of an array the []
> is required. whilst in python the variable name for a list is for
> instance bla, in csound the array name is kbla, but at initialization it
> is kbla[]. i understand that it is not possible to write
> kArr init 5
> because the parser needs to know that the variable is not meant as a
> number which is set to 5, but as an array which is set to length 5.
>
> so, yes, i think too that it is for now the best solution to use kArr[]
> at initialization because it has to be, but to write kArr anyway.
>
> in this logic: would it not be better if we used the pure variable name
> for the fill opcode, too? now it is:
> kArr[] fill 1,-7.12345, sqrt(2)
> but perhaps better:
> kArr fill 1,-7.12345, sqrt(2)
> ?
>
> best -
>         joachim
>
>
> Am 03.05.2013 00:25, schrieb Steven Yi:
>> Hi Joachim and Andres,
>>
>> I think allowing both would be difficult, and might be a mistake to
>> have multiple options (becomes a parser/semantic issue, also becomes a
>> pedagogical issue to explain why it works two different ways).
>>
>> Also, the idea of the declaring of type for a var and using the var
>> are sort of mixed in Csound.  In most other languages though, this
>> isn't the case. Types are inferred, or declared but not necessarily
>> part of the name.  For either, let's consider precedents in other
>> languages.  Something like C/C++/Java would have:
>>
>> float myVals[128];
>> doSomething(myVals);  // void doSomething(float[] inarg);
>>
>> Python has lists:
>>
>> a = []
>> doSomething(a)
>>
>> (blanking here, does python have arrays?)
>>
>> Ruby has something similar:
>>
>> a = []
>> doSomething(a)
>>
>> all of these languages use a post-fix operator for array access, i.e.:
>>
>> a[5] = 4
>> x = a[1] + a[2]
>>
>> I think most of the functional languages deal with lists rather than
>> arrays, and end up using array accessing functions rather than
>> post-fix operators.  The ones I can think of at the moment (Haskell,
>> Clojure, Common Lisp, Scheme, OCaml) don't really use array [] syntax
>> for creating and accessing items, and don't add something like [] to
>> the variable's name itself.
>>
>> For domain specific music languages, SAOL [1] and Supercollider [2]
>> also don't associate the type with the var name.
>>
>> Now, in Csound, through now we have had this mandatory semantic
>> requirement where var names have their type encoded within their names
>> (i.e. first letter denotes type).  With Csound 6, we don't necessarily
>> have to make this a requirement anymore in its current form.  We can
>> imagine arrays as a first demonstration of this, but that it also
>> leaves room for further typing possbilities, such as:
>>
>> data MyAmbisonicsType kx, ky, kz, kw
>>
>> myVar:MyAmbisonicsType init 0, 0, 0, 0
>>
>> asig myAmbiUdo myVar, .5, .5
>>
>> Something like this would allow user-defined types, but extends what
>> is going on with arrays as they are now, where first declaration of
>> var has type declared, and future uses only require the name.
>>
>> So, to sum up, I see two big reasons to go without requiring [] as
>> part of an array's name:
>>
>> 1) Other languages I'm aware of do it that way, and so this should be
>> easier to learn for those coming from other languages
>> 2) Semantically this convention should allow for Csound language
>> growth to work with future type work, which would include type
>> inference and dynamic typing amongst other things.
>>
>> If I've gotten anything wrong above, please let me know, as it's been
>> a long day here for me. :P
>>
>> Thanks!
>> steven
>>
>>
>> [1] - http://www.cs.berkeley.edu/~lazzaro/sa/book/saol/exstat/index.html#array
>> [2] - http://danielnouri.org/docs/SuperColliderHelp/Collections/Array.html
>>
>>
>>
>>
>> On Thu, May 2, 2013 at 12:58 PM, joachim heintz  wrote:
>>> hi steven -
>>>
>>> thanks! as andrés mentioned, it might be more consistent to have the
>>> var[] notation in general for array variables. would it be difficult to
>>> allow both:
>>> kMax       maxtab     kArr
>>> AND
>>> kMax       maxtab     kArr[]
>>> ?
>>>
>>> best -
>>>
>>>          joachim
>>>
>>>
>>> Am 01.05.2013 22:58, schrieb Steven Yi:
>>>> Hi Joachim,
>>>>
>>>> Array vars when used as arguments to opcodes should be just the
>>>> variable name without [].  For example:
>>>>
>>>> kMax       maxtab     kArr
>>>>
>>>> The use of [] after a variable name is only used to define/init an array var.
>>>>
>>>> Hope that helps!
>>>> steven
>>>>
>>>> On Wed, May 1, 2013 at 6:31 PM, joachim heintz  wrote:
>>>>> i am going on with some manual examples for the array opcodes. some
>>>>> questions related to maxtab:
>>>>>
>>>>> 1) it looks like maxtab does not accept the array notation (like kArr[])
>>>>> at all. when i run the example below, i get this error message:
>>>>> error: syntax error, unexpected ']'  (token "]") line 20:
>>>>>    >>>kMax       maxtab     kArr[] <<<
>>>>> so perhaps i misunderstood that the tab opcodes can be used for the new
>>>>> arrays, too?
>>>>>
>>>>> 2) tarmo suggested that the maxtab/mintab opcodes would return the
>>>>> position of the element being found, too. i think this would indeed be
>>>>> very useful. could the opcode be extended to this form:
>>>>> kmax [,kpos] maxtab tab
>>>>> ?
>>>>>
>>>>> 3) if also for arrays (or even for tables): could there be an
>>>>> init-version, too?
>>>>>
>>>>> best -
>>>>>
>>>>>           joachim
>>>>>
>>>>>
>>>>> 
>>>>> 
>>>>> ; Select audio/midi flags here according to platform
>>>>> -n
>>>>> 
>>>>> 
>>>>>
>>>>>               seed       0
>>>>>
>>>>> instr 1
>>>>> ;create an array with 10 elements
>>>>> kArr[]     init       10
>>>>> ;fill in random numbers and print them out
>>>>> kndx       =          0
>>>>>               until      kndx == 10 do
>>>>> kNum       random     -100, 100
>>>>> kArr[kndx] =          kNum
>>>>>               printf     "kArr[%d] = %f\n", kndx+1, kndx, kNum
>>>>> kndx       +=         1
>>>>> od
>>>>> ;investigate maximum number and print it out
>>>>> kMax       maxtab     kArr[]
>>>>>               printf     "Maximum of kArr[] = %f\n", kndx+1, kMax
>>>>>               turnoff
>>>>> endin
>>>>> 
>>>>> 
>>>>> i1 0 0.1
>>>>> e
>>>>> 
>>>>> 
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
>>>>> Get 100% visibility into your production application - at no cost.
>>>>> Code-level diagnostics for performance bottlenecks with <2% overhead
>>>>> Download for free and get started troubleshooting in minutes.
>>>>> http://p.sf.net/sfu/appdyn_d2d_ap1
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
>>>> Get 100% visibility into your production application - at no cost.
>>>> Code-level diagnostics for performance bottlenecks with <2% overhead
>>>> Download for free and get started troubleshooting in minutes.
>>>> http://p.sf.net/sfu/appdyn_d2d_ap1
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
>>> Get 100% visibility into your production application - at no cost.
>>> Code-level diagnostics for performance bottlenecks with <2% overhead
>>> Download for free and get started troubleshooting in minutes.
>>> http://p.sf.net/sfu/appdyn_d2d_ap1
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Get 100% visibility into Java/.NET code with AppDynamics Lite
>> It's a free troubleshooting tool designed for production
>> Get down to code-level detail for bottlenecks, with <2% overhead.
>> Download for free and get started troubleshooting in minutes.
>> http://p.sf.net/sfu/appdyn_d2d_ap2
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

hi steven -

do i understand correctly that an array variable must have been declared 
once with brackets, and can then afterwards be used without brackets?

if so, could fillarray do this implicitely, because this opcode "knows" 
that the LHS is meant as an array variable?

looking forward to an array of beer in graz for us the next days -

	joachim


Am 07.05.2013 13:32, schrieb Steven Yi:
> Hi Joachim,
>
> Thanks for the thoughtful points; I think it highlights some of the
> tricky areas we need to figure out in guiding the evolution of the
> language.  Regarding fillarray, the left-hand side (LHS) is using
> kArr[] for a newly declared array.  However, it should be possible to
> do:
>
> kArr[] init 3
> kArr fillarray 1,-7.12345, sqrt(2)
>
> By the time the 2nd line is evaluated, the first line has already
> declared and initialized "kArr" as an array of k-vals.
>
> Thanks!
> steven
>
> On Fri, May 3, 2013 at 9:23 PM, joachim heintz  wrote:
>> hi steven -
>>
>> thanks for this thorough answer! i am totally pro the flexibility of
>> variable names. (and what you write about the possibility to release the
>> mandatory i-,k- etc declaration is very exciting!!)
>>
>> i think the problems is because at the initialization of an array the []
>> is required. whilst in python the variable name for a list is for
>> instance bla, in csound the array name is kbla, but at initialization it
>> is kbla[]. i understand that it is not possible to write
>> kArr init 5
>> because the parser needs to know that the variable is not meant as a
>> number which is set to 5, but as an array which is set to length 5.
>>
>> so, yes, i think too that it is for now the best solution to use kArr[]
>> at initialization because it has to be, but to write kArr anyway.
>>
>> in this logic: would it not be better if we used the pure variable name
>> for the fill opcode, too? now it is:
>> kArr[] fill 1,-7.12345, sqrt(2)
>> but perhaps better:
>> kArr fill 1,-7.12345, sqrt(2)
>> ?
>>
>> best -
>>          joachim
>>
>>
>> Am 03.05.2013 00:25, schrieb Steven Yi:
>>> Hi Joachim and Andres,
>>>
>>> I think allowing both would be difficult, and might be a mistake to
>>> have multiple options (becomes a parser/semantic issue, also becomes a
>>> pedagogical issue to explain why it works two different ways).
>>>
>>> Also, the idea of the declaring of type for a var and using the var
>>> are sort of mixed in Csound.  In most other languages though, this
>>> isn't the case. Types are inferred, or declared but not necessarily
>>> part of the name.  For either, let's consider precedents in other
>>> languages.  Something like C/C++/Java would have:
>>>
>>> float myVals[128];
>>> doSomething(myVals);  // void doSomething(float[] inarg);
>>>
>>> Python has lists:
>>>
>>> a = []
>>> doSomething(a)
>>>
>>> (blanking here, does python have arrays?)
>>>
>>> Ruby has something similar:
>>>
>>> a = []
>>> doSomething(a)
>>>
>>> all of these languages use a post-fix operator for array access, i.e.:
>>>
>>> a[5] = 4
>>> x = a[1] + a[2]
>>>
>>> I think most of the functional languages deal with lists rather than
>>> arrays, and end up using array accessing functions rather than
>>> post-fix operators.  The ones I can think of at the moment (Haskell,
>>> Clojure, Common Lisp, Scheme, OCaml) don't really use array [] syntax
>>> for creating and accessing items, and don't add something like [] to
>>> the variable's name itself.
>>>
>>> For domain specific music languages, SAOL [1] and Supercollider [2]
>>> also don't associate the type with the var name.
>>>
>>> Now, in Csound, through now we have had this mandatory semantic
>>> requirement where var names have their type encoded within their names
>>> (i.e. first letter denotes type).  With Csound 6, we don't necessarily
>>> have to make this a requirement anymore in its current form.  We can
>>> imagine arrays as a first demonstration of this, but that it also
>>> leaves room for further typing possbilities, such as:
>>>
>>> data MyAmbisonicsType kx, ky, kz, kw
>>>
>>> myVar:MyAmbisonicsType init 0, 0, 0, 0
>>>
>>> asig myAmbiUdo myVar, .5, .5
>>>
>>> Something like this would allow user-defined types, but extends what
>>> is going on with arrays as they are now, where first declaration of
>>> var has type declared, and future uses only require the name.
>>>
>>> So, to sum up, I see two big reasons to go without requiring [] as
>>> part of an array's name:
>>>
>>> 1) Other languages I'm aware of do it that way, and so this should be
>>> easier to learn for those coming from other languages
>>> 2) Semantically this convention should allow for Csound language
>>> growth to work with future type work, which would include type
>>> inference and dynamic typing amongst other things.
>>>
>>> If I've gotten anything wrong above, please let me know, as it's been
>>> a long day here for me. :P
>>>
>>> Thanks!
>>> steven
>>>
>>>
>>> [1] - http://www.cs.berkeley.edu/~lazzaro/sa/book/saol/exstat/index.html#array
>>> [2] - http://danielnouri.org/docs/SuperColliderHelp/Collections/Array.html
>>>
>>>
>>>
>>>
>>> On Thu, May 2, 2013 at 12:58 PM, joachim heintz  wrote:
>>>> hi steven -
>>>>
>>>> thanks! as andrés mentioned, it might be more consistent to have the
>>>> var[] notation in general for array variables. would it be difficult to
>>>> allow both:
>>>> kMax       maxtab     kArr
>>>> AND
>>>> kMax       maxtab     kArr[]
>>>> ?
>>>>
>>>> best -
>>>>
>>>>           joachim
>>>>
>>>>
>>>> Am 01.05.2013 22:58, schrieb Steven Yi:
>>>>> Hi Joachim,
>>>>>
>>>>> Array vars when used as arguments to opcodes should be just the
>>>>> variable name without [].  For example:
>>>>>
>>>>> kMax       maxtab     kArr
>>>>>
>>>>> The use of [] after a variable name is only used to define/init an array var.
>>>>>
>>>>> Hope that helps!
>>>>> steven
>>>>>
>>>>> On Wed, May 1, 2013 at 6:31 PM, joachim heintz  wrote:
>>>>>> i am going on with some manual examples for the array opcodes. some
>>>>>> questions related to maxtab:
>>>>>>
>>>>>> 1) it looks like maxtab does not accept the array notation (like kArr[])
>>>>>> at all. when i run the example below, i get this error message:
>>>>>> error: syntax error, unexpected ']'  (token "]") line 20:
>>>>>>     >>>kMax       maxtab     kArr[] <<<
>>>>>> so perhaps i misunderstood that the tab opcodes can be used for the new
>>>>>> arrays, too?
>>>>>>
>>>>>> 2) tarmo suggested that the maxtab/mintab opcodes would return the
>>>>>> position of the element being found, too. i think this would indeed be
>>>>>> very useful. could the opcode be extended to this form:
>>>>>> kmax [,kpos] maxtab tab
>>>>>> ?
>>>>>>
>>>>>> 3) if also for arrays (or even for tables): could there be an
>>>>>> init-version, too?
>>>>>>
>>>>>> best -
>>>>>>
>>>>>>            joachim
>>>>>>
>>>>>>
>>>>>> 
>>>>>> 
>>>>>> ; Select audio/midi flags here according to platform
>>>>>> -n
>>>>>> 
>>>>>> 
>>>>>>
>>>>>>                seed       0
>>>>>>
>>>>>> instr 1
>>>>>> ;create an array with 10 elements
>>>>>> kArr[]     init       10
>>>>>> ;fill in random numbers and print them out
>>>>>> kndx       =          0
>>>>>>                until      kndx == 10 do
>>>>>> kNum       random     -100, 100
>>>>>> kArr[kndx] =          kNum
>>>>>>                printf     "kArr[%d] = %f\n", kndx+1, kndx, kNum
>>>>>> kndx       +=         1
>>>>>> od
>>>>>> ;investigate maximum number and print it out
>>>>>> kMax       maxtab     kArr[]
>>>>>>                printf     "Maximum of kArr[] = %f\n", kndx+1, kMax
>>>>>>                turnoff
>>>>>> endin
>>>>>> 
>>>>>> 
>>>>>> i1 0 0.1
>>>>>> e
>>>>>> 
>>>>>> 
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
>>>>>> Get 100% visibility into your production application - at no cost.
>>>>>> Code-level diagnostics for performance bottlenecks with <2% overhead
>>>>>> Download for free and get started troubleshooting in minutes.
>>>>>> http://p.sf.net/sfu/appdyn_d2d_ap1
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
>>>>> Get 100% visibility into your production application - at no cost.
>>>>> Code-level diagnostics for performance bottlenecks with <2% overhead
>>>>> Download for free and get started troubleshooting in minutes.
>>>>> http://p.sf.net/sfu/appdyn_d2d_ap1
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
>>>> Get 100% visibility into your production application - at no cost.
>>>> Code-level diagnostics for performance bottlenecks with <2% overhead
>>>> Download for free and get started troubleshooting in minutes.
>>>> http://p.sf.net/sfu/appdyn_d2d_ap1
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>> ------------------------------------------------------------------------------
>>> Get 100% visibility into Java/.NET code with AppDynamics Lite
>>> It's a free troubleshooting tool designed for production
>>> Get down to code-level detail for bottlenecks, with <2% overhead.
>>> Download for free and get started troubleshooting in minutes.
>>> http://p.sf.net/sfu/appdyn_d2d_ap2
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>> ------------------------------------------------------------------------------
>> Get 100% visibility into Java/.NET code with AppDynamics Lite
>> It's a free troubleshooting tool designed for production
>> Get down to code-level detail for bottlenecks, with <2% overhead.
>> Download for free and get started troubleshooting in minutes.
>> http://p.sf.net/sfu/appdyn_d2d_ap2
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and
> their applications. This 200-page book is written by three acclaimed
> leaders in the field. The early access version is available now.
> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourc

Hi Joachim,

You are correct about requiring the first time declaration of arrays
to have [].  This is modeled on C code:

int myValues[128];

void doSomething(int args[]) {
  ... does something ...
}

doSomething(myValues);   // Note no brackets when passing array variable around

NOTE: The following is a bit of a long answer, but I think it's
important to understand the analysis of the Csound language as it is
and what's happened in CS6 to understand where it can go forward.

[TL;DR - Csound has static types now, but can possibly have dynamic
typing in the future.]

Currently, it would not be possible for fillarray to "know" its output
and automatically cast the LHS to an array.  Csound is today a
statically typed language.  Types are declared using the first letter
of the variable name.  This mechanism for typing of variables has--as
far as I know--been there since the beginning, and is reflected in the
compiler with the use of the argtyp2 function which resolves the
variable's type by looking at that first letter.

In the pre-CS6, types were constantly looked up against the first
letter of the variable whenever the type of the variable was needed.
In CS6, this has changed such that upon the first time a variable is
encountered, its type is determined using the first letter, and an
CS_VAR entry is added.  Afterwards, later checks look to see if a var
is defined and if so, grab it's declared type, otherwise add a CS_VAR
definition for it (or fail if it's supposed to be defined at that
point).  Changing the primary mechanism for how variable's types are
known to use a lookup rather than re-reading it from the var allows
two distinct things to happen:

1. The type system can be modified to allow for a newer form of
explicit typing, such as:

kmyVar2 = 1
myVar:k = 1  ; equivalent definition of k var type
myArr:k[] init 2  ; definition of myArr with k[] type
myValues:MyCustomType init 3, 4, 5   ; definition of myValues to a MyCustomType
myUdo kmyVar2, myVar, myArr, myValues

In the last line, because we are now doing lookup rather than reading
from var name, we can know that the types of those in-args to myUdo.


2. The type system can be modified to allow for dynamic typing using
type inference, such as:

myOutSig vco2 .5, 440
out myOutSig

This is, I think, the more interesting of the two possibilities, but
also problematic due to the legacy of the Csound language.  Regarding
type inference, pre-CS6 had a form of it when resolving expressions.
Something like this:

kval init  3 + 4
kvar init cpspch(4.5)

was resolved using some hand-done code that looked at the types of the
args, then synthesized one depending on those types.  In CS6, this was
changed so that a lookup of possible opcodes is actually done together
with the arg types, and from the found opcode entries (not just the
arg types), the type of the output arg is resolved and that is used.
This change allowed any opcode to be used within an expression using
function call syntax as well as allowed any number of arguments to
function calls.

However, this also highlighted the problematic nature of the Csound
language regarding polymorphism.  In most programming languages,
functions with the same name and same input types can not have
different output types.  However, with things like oscil, we have a
polymorphism that depends on the output type.  IMO, this is the single
biggest difficulty in terms of allowing us to implement dynamic
typing.

There may be some possible paths to go forward, but it's all a bit
hazy at the moment.  I can imagine with a more evolved type system,
perhaps drawing on something like Hindley-Milner [1] as used in ML or
in Haskell, we might be able to infer the types of variables with
multiple passes and temporary free types. I think we'll run into
ambiguities though, where a var could be synthesized as a k- or a- and
be completely semantically correct either way.  It is because of that
we would need some intervention by declaring the exact type to be used
(either on the variable or declaring what form of opcode to use), but
requiring that might be non-backwards compatible.  We could introduce
a fall-back mechanism to the type inference, such that if it can not
be resolved with the normal means, try to see if a var's name has type
info that could help resolve that.  That'd then possibly give us
something that could work with older projects.  That would still give
ambiguities for the situation of functional call syntax, where
intermediary vars are not named, but a type declaration using
something like oscil:k or oscil:a might solve that.

Well, hopefully that explains a bit of what's going on internally and
how that could affect the external language of Csound.

Thanks!
steven


[1] - http://en.wikipedia.org/wiki/Hindley%E2%80%93Milner

On Tue, May 7, 2013 at 4:31 PM, joachim heintz  wrote:
> hi steven -
>
> do i understand correctly that an array variable must have been declared
> once with brackets, and can then afterwards be used without brackets?
>
> if so, could fillarray do this implicitely, because this opcode "knows"
> that the LHS is meant as an array variable?
>
> looking forward to an array of beer in graz for us the next days -
>
>         joachim
>
>
> Am 07.05.2013 13:32, schrieb Steven Yi:
>> Hi Joachim,
>>
>> Thanks for the thoughtful points; I think it highlights some of the
>> tricky areas we need to figure out in guiding the evolution of the
>> language.  Regarding fillarray, the left-hand side (LHS) is using
>> kArr[] for a newly declared array.  However, it should be possible to
>> do:
>>
>> kArr[] init 3
>> kArr fillarray 1,-7.12345, sqrt(2)
>>
>> By the time the 2nd line is evaluated, the first line has already
>> declared and initialized "kArr" as an array of k-vals.
>>
>> Thanks!
>> steven
>>
>> On Fri, May 3, 2013 at 9:23 PM, joachim heintz  wrote:
>>> hi steven -
>>>
>>> thanks for this thorough answer! i am totally pro the flexibility of
>>> variable names. (and what you write about the possibility to release the
>>> mandatory i-,k- etc declaration is very exciting!!)
>>>
>>> i think the problems is because at the initialization of an array the []
>>> is required. whilst in python the variable name for a list is for
>>> instance bla, in csound the array name is kbla, but at initialization it
>>> is kbla[]. i understand that it is not possible to write
>>> kArr init 5
>>> because the parser needs to know that the variable is not meant as a
>>> number which is set to 5, but as an array which is set to length 5.
>>>
>>> so, yes, i think too that it is for now the best solution to use kArr[]
>>> at initialization because it has to be, but to write kArr anyway.
>>>
>>> in this logic: would it not be better if we used the pure variable name
>>> for the fill opcode, too? now it is:
>>> kArr[] fill 1,-7.12345, sqrt(2)
>>> but perhaps better:
>>> kArr fill 1,-7.12345, sqrt(2)
>>> ?
>>>
>>> best -
>>>          joachim
>>>
>>>
>>> Am 03.05.2013 00:25, schrieb Steven Yi:
>>>> Hi Joachim and Andres,
>>>>
>>>> I think allowing both would be difficult, and might be a mistake to
>>>> have multiple options (becomes a parser/semantic issue, also becomes a
>>>> pedagogical issue to explain why it works two different ways).
>>>>
>>>> Also, the idea of the declaring of type for a var and using the var
>>>> are sort of mixed in Csound.  In most other languages though, this
>>>> isn't the case. Types are inferred, or declared but not necessarily
>>>> part of the name.  For either, let's consider precedents in other
>>>> languages.  Something like C/C++/Java would have:
>>>>
>>>> float myVals[128];
>>>> doSomething(myVals);  // void doSomething(float[] inarg);
>>>>
>>>> Python has lists:
>>>>
>>>> a = []
>>>> doSomething(a)
>>>>
>>>> (blanking here, does python have arrays?)
>>>>
>>>> Ruby has something similar:
>>>>
>>>> a = []
>>>> doSomething(a)
>>>>
>>>> all of these languages use a post-fix operator for array access, i.e.:
>>>>
>>>> a[5] = 4
>>>> x = a[1] + a[2]
>>>>
>>>> I think most of the functional languages deal with lists rather than
>>>> arrays, and end up using array accessing functions rather than
>>>> post-fix operators.  The ones I can think of at the moment (Haskell,
>>>> Clojure, Common Lisp, Scheme, OCaml) don't really use array [] syntax
>>>> for creating and accessing items, and don't add something like [] to
>>>> the variable's name itself.
>>>>
>>>> For domain specific music languages, SAOL [1] and Supercollider [2]
>>>> also don't associate the type with the var name.
>>>>
>>>> Now, in Csound, through now we have had this mandatory semantic
>>>> requirement where var names have their type encoded within their names
>>>> (i.e. first letter denotes type).  With Csound 6, we don't necessarily
>>>> have to make this a requirement anymore in its current form.  We can
>>>> imagine arrays as a first demonstration of this, but that it also
>>>> leaves room for further typing possbilities, such as:
>>>>
>>>> data MyAmbisonicsType kx, ky, kz, kw
>>>>
>>>> myVar:MyAmbisonicsType init 0, 0, 0, 0
>>>>
>>>> asig myAmbiUdo myVar, .5, .5
>>>>
>>>> Something like this would allow user-defined types, but extends what
>>>> is going on with arrays as they are now, where first declaration of
>>>> var has type declared, and future uses only require the name.
>>>>
>>>> So, to sum up, I see two big reasons to go without requiring [] as
>>>> part of an array's name:
>>>>
>>>> 1) Other languages I'm aware of do it that way, and so this should be
>>>> easier to learn for those coming from other languages
>>>> 2) Semantically this convention should allow for Csound language
>>>> growth to work with future type work, which would include type
>>>> inference and dynamic typing amongst other things.
>>>>
>>>> If I've gotten anything wrong above, please let me know, as it's been
>>>> a long day here for me. :P
>>>>
>>>> Thanks!
>>>> steven
>>>>
>>>>
>>>> [1] - http://www.cs.berkeley.edu/~lazzaro/sa/book/saol/exstat/index.html#array
>>>> [2] - http://danielnouri.org/docs/SuperColliderHelp/Collections/Array.html
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, May 2, 2013 at 12:58 PM, joachim heintz  wrote:
>>>>> hi steven -
>>>>>
>>>>> thanks! as andrés mentioned, it might be more consistent to have the
>>>>> var[] notation in general for array variables. would it be difficult to
>>>>> allow both:
>>>>> kMax       maxtab     kArr
>>>>> AND
>>>>> kMax       maxtab     kArr[]
>>>>> ?
>>>>>
>>>>> best -
>>>>>
>>>>>           joachim
>>>>>
>>>>>
>>>>> Am 01.05.2013 22:58, schrieb Steven Yi:
>>>>>> Hi Joachim,
>>>>>>
>>>>>> Array vars when used as arguments to opcodes should be just the
>>>>>> variable name without [].  For example:
>>>>>>
>>>>>> kMax       maxtab     kArr
>>>>>>
>>>>>> The use of [] after a variable name is only used to define/init an array var.
>>>>>>
>>>>>> Hope that helps!
>>>>>> steven
>>>>>>
>>>>>> On Wed, May 1, 2013 at 6:31 PM, joachim heintz  wrote:
>>>>>>> i am going on with some manual examples for the array opcodes. some
>>>>>>> questions related to maxtab:
>>>>>>>
>>>>>>> 1) it looks like maxtab does not accept the array notation (like kArr[])
>>>>>>> at all. when i run the example below, i get this error message:
>>>>>>> error: syntax error, unexpected ']'  (token "]") line 20:
>>>>>>>     >>>kMax       maxtab     kArr[] <<<
>>>>>>> so perhaps i misunderstood that the tab opcodes can be used for the new
>>>>>>> arrays, too?
>>>>>>>
>>>>>>> 2) tarmo suggested that the maxtab/mintab opcodes would return the
>>>>>>> position of the element being found, too. i think this would indeed be
>>>>>>> very useful. could the opcode be extended to this form:
>>>>>>> kmax [,kpos] maxtab tab
>>>>>>> ?
>>>>>>>
>>>>>>> 3) if also for arrays (or even for tables): could there be an
>>>>>>> init-version, too?
>>>>>>>
>>>>>>> best -
>>>>>>>
>>>>>>>            joachim
>>>>>>>
>>>>>>>
>>>>>>> 
>>>>>>> 
>>>>>>> ; Select audio/midi flags here according to platform
>>>>>>> -n
>>>>>>> 
>>>>>>> 
>>>>>>>
>>>>>>>                seed       0
>>>>>>>
>>>>>>> instr 1
>>>>>>> ;create an array with 10 elements
>>>>>>> kArr[]     init       10
>>>>>>> ;fill in random numbers and print them out
>>>>>>> kndx       =          0
>>>>>>>                until      kndx == 10 do
>>>>>>> kNum       random     -100, 100
>>>>>>> kArr[kndx] =          kNum
>>>>>>>                printf     "kArr[%d] = %f\n", kndx+1, kndx, kNum
>>>>>>> kndx       +=         1
>>>>>>> od
>>>>>>> ;investigate maximum number and print it out
>>>>>>> kMax       maxtab     kArr[]
>>>>>>>                printf     "Maximum of kArr[] = %f\n", kndx+1, kMax
>>>>>>>                turnoff
>>>>>>> endin
>>>>>>> 
>>>>>>> 
>>>>>>> i1 0 0.1
>>>>>>> e
>>>>>>> 
>>>>>>> 
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
>>>>>>> Get 100% visibility into your production application - at no cost.
>>>>>>> Code-level diagnostics for performance bottlenecks with <2% overhead
>>>>>>> Download for free and get started troubleshooting in minutes.
>>>>>>> http://p.sf.net/sfu/appdyn_d2d_ap1
>>>>>>> _______________________________________________
>>>>>>> Csound-devel mailing list
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
>>>>>> Get 100% visibility into your production application - at no cost.
>>>>>> Code-level diagnostics for performance bottlenecks with <2% overhead
>>>>>> Download for free and get started troubleshooting in minutes.
>>>>>> http://p.sf.net/sfu/appdyn_d2d_ap1
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
>>>>> Get 100% visibility into your production application - at no cost.
>>>>> Code-level diagnostics for performance bottlenecks with <2% overhead
>>>>> Download for free and get started troubleshooting in minutes.
>>>>> http://p.sf.net/sfu/appdyn_d2d_ap1
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Get 100% visibility into Java/.NET code with AppDynamics Lite
>>>> It's a free troubleshooting tool designed for production
>>>> Get down to code-level detail for bottlenecks, with <2% overhead.
>>>> Download for free and get started troubleshooting in minutes.
>>>> http://p.sf.net/sfu/appdyn_d2d_ap2
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Get 100% visibility into Java/.NET code with AppDynamics Lite
>>> It's a free troubleshooting tool designed for production
>>> Get down to code-level detail for bottlenecks, with <2% overhead.
>>> Download for free and get started troubleshooting in minutes.
>>> http://p.sf.net/sfu/appdyn_d2d_ap2
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and
>> their applications. This 200-page book is written by three acclaimed
>> leaders in the field. The early access version is available now.
>> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and
> their applications. This 200-page book is written by three acclaimed
> leaders in the field. The early access version is available now.
> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

hi steven -

thanks very much for taking the time for this answer! indeed, my image 
of what happens internally has become much clearer because of it.

i see again, too, what a complicated work results from the credo to 
guarantee backwards compatibility. and i am convinced that this decision 
is right and is more valuable from year to year. i am happy to accept 
certain complications in usage because of it, and the more when i 
understand these backgrounds.

see you ...

	j



Am 08.05.2013 14:18, schrieb Steven Yi:
> Hi Joachim,
>
> You are correct about requiring the first time declaration of arrays
> to have [].  This is modeled on C code:
>
> int myValues[128];
>
> void doSomething(int args[]) {
>    ... does something ...
> }
>
> doSomething(myValues);   // Note no brackets when passing array variable around
>
> NOTE: The following is a bit of a long answer, but I think it's
> important to understand the analysis of the Csound language as it is
> and what's happened in CS6 to understand where it can go forward.
>
> [TL;DR - Csound has static types now, but can possibly have dynamic
> typing in the future.]
>
> Currently, it would not be possible for fillarray to "know" its output
> and automatically cast the LHS to an array.  Csound is today a
> statically typed language.  Types are declared using the first letter
> of the variable name.  This mechanism for typing of variables has--as
> far as I know--been there since the beginning, and is reflected in the
> compiler with the use of the argtyp2 function which resolves the
> variable's type by looking at that first letter.
>
> In the pre-CS6, types were constantly looked up against the first
> letter of the variable whenever the type of the variable was needed.
> In CS6, this has changed such that upon the first time a variable is
> encountered, its type is determined using the first letter, and an
> CS_VAR entry is added.  Afterwards, later checks look to see if a var
> is defined and if so, grab it's declared type, otherwise add a CS_VAR
> definition for it (or fail if it's supposed to be defined at that
> point).  Changing the primary mechanism for how variable's types are
> known to use a lookup rather than re-reading it from the var allows
> two distinct things to happen:
>
> 1. The type system can be modified to allow for a newer form of
> explicit typing, such as:
>
> kmyVar2 = 1
> myVar:k = 1  ; equivalent definition of k var type
> myArr:k[] init 2  ; definition of myArr with k[] type
> myValues:MyCustomType init 3, 4, 5   ; definition of myValues to a MyCustomType
> myUdo kmyVar2, myVar, myArr, myValues
>
> In the last line, because we are now doing lookup rather than reading
> from var name, we can know that the types of those in-args to myUdo.
>
>
> 2. The type system can be modified to allow for dynamic typing using
> type inference, such as:
>
> myOutSig vco2 .5, 440
> out myOutSig
>
> This is, I think, the more interesting of the two possibilities, but
> also problematic due to the legacy of the Csound language.  Regarding
> type inference, pre-CS6 had a form of it when resolving expressions.
> Something like this:
>
> kval init  3 + 4
> kvar init cpspch(4.5)
>
> was resolved using some hand-done code that looked at the types of the
> args, then synthesized one depending on those types.  In CS6, this was
> changed so that a lookup of possible opcodes is actually done together
> with the arg types, and from the found opcode entries (not just the
> arg types), the type of the output arg is resolved and that is used.
> This change allowed any opcode to be used within an expression using
> function call syntax as well as allowed any number of arguments to
> function calls.
>
> However, this also highlighted the problematic nature of the Csound
> language regarding polymorphism.  In most programming languages,
> functions with the same name and same input types can not have
> different output types.  However, with things like oscil, we have a
> polymorphism that depends on the output type.  IMO, this is the single
> biggest difficulty in terms of allowing us to implement dynamic
> typing.
>
> There may be some possible paths to go forward, but it's all a bit
> hazy at the moment.  I can imagine with a more evolved type system,
> perhaps drawing on something like Hindley-Milner [1] as used in ML or
> in Haskell, we might be able to infer the types of variables with
> multiple passes and temporary free types. I think we'll run into
> ambiguities though, where a var could be synthesized as a k- or a- and
> be completely semantically correct either way.  It is because of that
> we would need some intervention by declaring the exact type to be used
> (either on the variable or declaring what form of opcode to use), but
> requiring that might be non-backwards compatible.  We could introduce
> a fall-back mechanism to the type inference, such that if it can not
> be resolved with the normal means, try to see if a var's name has type
> info that could help resolve that.  That'd then possibly give us
> something that could work with older projects.  That would still give
> ambiguities for the situation of functional call syntax, where
> intermediary vars are not named, but a type declaration using
> something like oscil:k or oscil:a might solve that.
>
> Well, hopefully that explains a bit of what's going on internally and
> how that could affect the external language of Csound.
>
> Thanks!
> steven
>
>
> [1] - http://en.wikipedia.org/wiki/Hindley%E2%80%93Milner
>
> On Tue, May 7, 2013 at 4:31 PM, joachim heintz  wrote:
>> hi steven -
>>
>> do i understand correctly that an array variable must have been declared
>> once with brackets, and can then afterwards be used without brackets?
>>
>> if so, could fillarray do this implicitely, because this opcode "knows"
>> that the LHS is meant as an array variable?
>>
>> looking forward to an array of beer in graz for us the next days -
>>
>>          joachim
>>
>>
>> Am 07.05.2013 13:32, schrieb Steven Yi:
>>> Hi Joachim,
>>>
>>> Thanks for the thoughtful points; I think it highlights some of the
>>> tricky areas we need to figure out in guiding the evolution of the
>>> language.  Regarding fillarray, the left-hand side (LHS) is using
>>> kArr[] for a newly declared array.  However, it should be possible to
>>> do:
>>>
>>> kArr[] init 3
>>> kArr fillarray 1,-7.12345, sqrt(2)
>>>
>>> By the time the 2nd line is evaluated, the first line has already
>>> declared and initialized "kArr" as an array of k-vals.
>>>
>>> Thanks!
>>> steven
>>>
>>> On Fri, May 3, 2013 at 9:23 PM, joachim heintz  wrote:
>>>> hi steven -
>>>>
>>>> thanks for this thorough answer! i am totally pro the flexibility of
>>>> variable names. (and what you write about the possibility to release the
>>>> mandatory i-,k- etc declaration is very exciting!!)
>>>>
>>>> i think the problems is because at the initialization of an array the []
>>>> is required. whilst in python the variable name for a list is for
>>>> instance bla, in csound the array name is kbla, but at initialization it
>>>> is kbla[]. i understand that it is not possible to write
>>>> kArr init 5
>>>> because the parser needs to know that the variable is not meant as a
>>>> number which is set to 5, but as an array which is set to length 5.
>>>>
>>>> so, yes, i think too that it is for now the best solution to use kArr[]
>>>> at initialization because it has to be, but to write kArr anyway.
>>>>
>>>> in this logic: would it not be better if we used the pure variable name
>>>> for the fill opcode, too? now it is:
>>>> kArr[] fill 1,-7.12345, sqrt(2)
>>>> but perhaps better:
>>>> kArr fill 1,-7.12345, sqrt(2)
>>>> ?
>>>>
>>>> best -
>>>>           joachim
>>>>
>>>>
>>>> Am 03.05.2013 00:25, schrieb Steven Yi:
>>>>> Hi Joachim and Andres,
>>>>>
>>>>> I think allowing both would be difficult, and might be a mistake to
>>>>> have multiple options (becomes a parser/semantic issue, also becomes a
>>>>> pedagogical issue to explain why it works two different ways).
>>>>>
>>>>> Also, the idea of the declaring of type for a var and using the var
>>>>> are sort of mixed in Csound.  In most other languages though, this
>>>>> isn't the case. Types are inferred, or declared but not necessarily
>>>>> part of the name.  For either, let's consider precedents in other
>>>>> languages.  Something like C/C++/Java would have:
>>>>>
>>>>> float myVals[128];
>>>>> doSomething(myVals);  // void doSomething(float[] inarg);
>>>>>
>>>>> Python has lists:
>>>>>
>>>>> a = []
>>>>> doSomething(a)
>>>>>
>>>>> (blanking here, does python have arrays?)
>>>>>
>>>>> Ruby has something similar:
>>>>>
>>>>> a = []
>>>>> doSomething(a)
>>>>>
>>>>> all of these languages use a post-fix operator for array access, i.e.:
>>>>>
>>>>> a[5] = 4
>>>>> x = a[1] + a[2]
>>>>>
>>>>> I think most of the functional languages deal with lists rather than
>>>>> arrays, and end up using array accessing functions rather than
>>>>> post-fix operators.  The ones I can think of at the moment (Haskell,
>>>>> Clojure, Common Lisp, Scheme, OCaml) don't really use array [] syntax
>>>>> for creating and accessing items, and don't add something like [] to
>>>>> the variable's name itself.
>>>>>
>>>>> For domain specific music languages, SAOL [1] and Supercollider [2]
>>>>> also don't associate the type with the var name.
>>>>>
>>>>> Now, in Csound, through now we have had this mandatory semantic
>>>>> requirement where var names have their type encoded within their names
>>>>> (i.e. first letter denotes type).  With Csound 6, we don't necessarily
>>>>> have to make this a requirement anymore in its current form.  We can
>>>>> imagine arrays as a first demonstration of this, but that it also
>>>>> leaves room for further typing possbilities, such as:
>>>>>
>>>>> data MyAmbisonicsType kx, ky, kz, kw
>>>>>
>>>>> myVar:MyAmbisonicsType init 0, 0, 0, 0
>>>>>
>>>>> asig myAmbiUdo myVar, .5, .5
>>>>>
>>>>> Something like this would allow user-defined types, but extends what
>>>>> is going on with arrays as they are now, where first declaration of
>>>>> var has type declared, and future uses only require the name.
>>>>>
>>>>> So, to sum up, I see two big reasons to go without requiring [] as
>>>>> part of an array's name:
>>>>>
>>>>> 1) Other languages I'm aware of do it that way, and so this should be
>>>>> easier to learn for those coming from other languages
>>>>> 2) Semantically this convention should allow for Csound language
>>>>> growth to work with future type work, which would include type
>>>>> inference and dynamic typing amongst other things.
>>>>>
>>>>> If I've gotten anything wrong above, please let me know, as it's been
>>>>> a long day here for me. :P
>>>>>
>>>>> Thanks!
>>>>> steven
>>>>>
>>>>>
>>>>> [1] - http://www.cs.berkeley.edu/~lazzaro/sa/book/saol/exstat/index.html#array
>>>>> [2] - http://danielnouri.org/docs/SuperColliderHelp/Collections/Array.html
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, May 2, 2013 at 12:58 PM, joachim heintz  wrote:
>>>>>> hi steven -
>>>>>>
>>>>>> thanks! as andrés mentioned, it might be more consistent to have the
>>>>>> var[] notation in general for array variables. would it be difficult to
>>>>>> allow both:
>>>>>> kMax       maxtab     kArr
>>>>>> AND
>>>>>> kMax       maxtab     kArr[]
>>>>>> ?
>>>>>>
>>>>>> best -
>>>>>>
>>>>>>            joachim
>>>>>>
>>>>>>
>>>>>> Am 01.05.2013 22:58, schrieb Steven Yi:
>>>>>>> Hi Joachim,
>>>>>>>
>>>>>>> Array vars when used as arguments to opcodes should be just the
>>>>>>> variable name without [].  For example:
>>>>>>>
>>>>>>> kMax       maxtab     kArr
>>>>>>>
>>>>>>> The use of [] after a variable name is only used to define/init an array var.
>>>>>>>
>>>>>>> Hope that helps!
>>>>>>> steven
>>>>>>>
>>>>>>> On Wed, May 1, 2013 at 6:31 PM, joachim heintz  wrote:
>>>>>>>> i am going on with some manual examples for the array opcodes. some
>>>>>>>> questions related to maxtab:
>>>>>>>>
>>>>>>>> 1) it looks like maxtab does not accept the array notation (like kArr[])
>>>>>>>> at all. when i run the example below, i get this error message:
>>>>>>>> error: syntax error, unexpected ']'  (token "]") line 20:
>>>>>>>>      >>>kMax       maxtab     kArr[] <<<
>>>>>>>> so perhaps i misunderstood that the tab opcodes can be used for the new
>>>>>>>> arrays, too?
>>>>>>>>
>>>>>>>> 2) tarmo suggested that the maxtab/mintab opcodes would return the
>>>>>>>> position of the element being found, too. i think this would indeed be
>>>>>>>> very useful. could the opcode be extended to this form:
>>>>>>>> kmax [,kpos] maxtab tab
>>>>>>>> ?
>>>>>>>>
>>>>>>>> 3) if also for arrays (or even for tables): could there be an
>>>>>>>> init-version, too?
>>>>>>>>
>>>>>>>> best -
>>>>>>>>
>>>>>>>>             joachim
>>>>>>>>
>>>>>>>>
>>>>>>>> 
>>>>>>>> 
>>>>>>>> ; Select audio/midi flags here according to platform
>>>>>>>> -n
>>>>>>>> 
>>>>>>>> 
>>>>>>>>
>>>>>>>>                 seed       0
>>>>>>>>
>>>>>>>> instr 1
>>>>>>>> ;create an array with 10 elements
>>>>>>>> kArr[]     init       10
>>>>>>>> ;fill in random numbers and print them out
>>>>>>>> kndx       =          0
>>>>>>>>                 until      kndx == 10 do
>>>>>>>> kNum       random     -100, 100
>>>>>>>> kArr[kndx] =          kNum
>>>>>>>>                 printf     "kArr[%d] = %f\n", kndx+1, kndx, kNum
>>>>>>>> kndx       +=         1
>>>>>>>> od
>>>>>>>> ;investigate maximum number and print it out
>>>>>>>> kMax       maxtab     kArr[]
>>>>>>>>                 printf     "Maximum of kArr[] = %f\n", kndx+1, kMax
>>>>>>>>                 turnoff
>>>>>>>> endin
>>>>>>>> 
>>>>>>>> 
>>>>>>>> i1 0 0.1
>>>>>>>> e
>>>>>>>> 
>>>>>>>> 
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
>>>>>>>> Get 100% visibility into your production application - at no cost.
>>>>>>>> Code-level diagnostics for performance bottlenecks with <2% overhead
>>>>>>>> Download for free and get started troubleshooting in minutes.
>>>>>>>> http://p.sf.net/sfu/appdyn_d2d_ap1
>>>>>>>> _______________________________________________
>>>>>>>> Csound-devel mailing list
>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
>>>>>>> Get 100% visibility into your production application - at no cost.
>>>>>>> Code-level diagnostics for performance bottlenecks with <2% overhead
>>>>>>> Download for free and get started troubleshooting in minutes.
>>>>>>> http://p.sf.net/sfu/appdyn_d2d_ap1
>>>>>>> _______________________________________________
>>>>>>> Csound-devel mailing list
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
>>>>>> Get 100% visibility into your production application - at no cost.
>>>>>> Code-level diagnostics for performance bottlenecks with <2% overhead
>>>>>> Download for free and get started troubleshooting in minutes.
>>>>>> http://p.sf.net/sfu/appdyn_d2d_ap1
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Get 100% visibility into Java/.NET code with AppDynamics Lite
>>>>> It's a free troubleshooting tool designed for production
>>>>> Get down to code-level detail for bottlenecks, with <2% overhead.
>>>>> Download for free and get started troubleshooting in minutes.
>>>>> http://p.sf.net/sfu/appdyn_d2d_ap2
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Get 100% visibility into Java/.NET code with AppDynamics Lite
>>>> It's a free troubleshooting tool designed for production
>>>> Get down to code-level detail for bottlenecks, with <2% overhead.
>>>> Download for free and get started troubleshooting in minutes.
>>>> http://p.sf.net/sfu/appdyn_d2d_ap2
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>> ------------------------------------------------------------------------------
>>> Learn Graph Databases - Download FREE O'Reilly Book
>>> "Graph Databases" is the definitive new guide to graph databases and
>>> their applications. This 200-page book is written by three acclaimed
>>> leaders in the field. The early access version is available now.
>>> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and
>> their applications. This 200-page book is written by three acclaimed
>> leaders in the field. The early access version is available now.
>> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and
> their applications. This 200-page book is written by three acclaimed
> leaders in the field. The early access version is available now.
> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourc