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