(longish e-mail alert)

Steven and I have been developing this function syntax for Csound and I think we reached a point
where it can be used with all opcodes with a single output (or multiple optional outputs, but using just a
single output). To enable this, we have introduced type annotations.

=======================
In general type annotation works like this:

1) opcodes with a single output type (k, a etc) can be used with no extra annotations

2) opcodes that have more than one output type (ie, they can be k- or a- rate depending on
the type of the output variable etc) may require annotation to select the correct opcode. This
has the form of opcode:type.

- when there is a default opcode that cannot be used correctly, for instance

chnset("hello\n", "hi")
prints(chnget("hi"))

new alloc for instr 1:
INIT ERROR in instr 1: channel already exists with incompatible type
#i0     chnget.i        "hi"
INIT ERROR in instr 1: printks param 1 was not a "quoted string"
        prints  #i0

then you need to select the correct type via an annotation

chnset("hello\n", "hi")
prints(chnget:S("hi"))

new alloc for instr 1:
hello

- when you want a particular opcode that is not the default one for the input types you've
asked:

out(oscili(oscili(1,1)*1000,440)*linen(1,0.1,p3,0.1))

will select a-rate oscili for amplitude modulation, and k-rate linen for envelope(defaults)

out(oscili(oscili:k(1,1)*1000,440)*linen:a(1,0.1,p3,0.1))

will select k-rate oscili for amplitude modulation, and a-rate linen for envelope.

Note that in both cases, the carrier oscillator does not need an annotation because the
defaults for the input types are always correct. You can still use the annotation, but it
will not make a difference. If the incorrect annotation is used, you will get a syntax error
as expected.

- finally with opcodes with multiple out args, type annotations are mandatory

outs(diskin2("fox.wav",1))

error:  Unable to find opcode entry for 'outs' with matching argument types:
Found: (null) outs mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
Line: 6 Loc: 1

is fixed with

out(diskin2:a("fox.wav",1))

new alloc for instr 1:
diskin2: opened '/Users/victor/audio/fox.wav':
         44100 Hz, 1 channel(s), 121569 sample frames

=================================

We are hoping to introduce support for multiple outputs later, but for the moment, this appears to
be quite functional (excuse me the pun). It can be intermixed with the usual Csound syntax to allow
fantastic unreadability. ;)

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie




------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

Would it make sense to use a dot instead of a colon?

line.k(...)

I would prefer if we pulled Csound syntax closer to C or python when possible, rather than away.

Cheers,
Andrés

On Thu, May 23, 2013 at 2:44 AM, Victor Lazzarini <Victor.Lazzarini@nuim.ie> wrote:

(longish e-mail alert)

Steven and I have been developing this function syntax for Csound and I think we reached a point
where it can be used with all opcodes with a single output (or multiple optional outputs, but using just a
single output). To enable this, we have introduced type annotations.

=======================
In general type annotation works like this:

1) opcodes with a single output type (k, a etc) can be used with no extra annotations

2) opcodes that have more than one output type (ie, they can be k- or a- rate depending on
the type of the output variable etc) may require annotation to select the correct opcode. This
has the form of opcode:type.

- when there is a default opcode that cannot be used correctly, for instance

chnset("hello\n", "hi")
prints(chnget("hi"))

new alloc for instr 1:
INIT ERROR in instr 1: channel already exists with incompatible type
#i0     chnget.i        "hi"
INIT ERROR in instr 1: printks param 1 was not a "quoted string"
        prints  #i0

then you need to select the correct type via an annotation

chnset("hello\n", "hi")
prints(chnget:S("hi"))

new alloc for instr 1:
hello

- when you want a particular opcode that is not the default one for the input types you've
asked:

out(oscili(oscili(1,1)*1000,440)*linen(1,0.1,p3,0.1))

will select a-rate oscili for amplitude modulation, and k-rate linen for envelope(defaults)

out(oscili(oscili:k(1,1)*1000,440)*linen:a(1,0.1,p3,0.1))

will select k-rate oscili for amplitude modulation, and a-rate linen for envelope.

Note that in both cases, the carrier oscillator does not need an annotation because the
defaults for the input types are always correct. You can still use the annotation, but it
will not make a difference. If the incorrect annotation is used, you will get a syntax error
as expected.

- finally with opcodes with multiple out args, type annotations are mandatory

outs(diskin2("fox.wav",1))

error:  Unable to find opcode entry for 'outs' with matching argument types:
Found: (null) outs mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
Line: 6 Loc: 1

is fixed with

out(diskin2:a("fox.wav",1))

new alloc for instr 1:
diskin2: opened '/Users/victor/audio/fox.wav':
         44100 Hz, 1 channel(s), 121569 sample frames

=================================

We are hoping to introduce support for multiple outputs later, but for the moment, this appears to
be quite functional (excuse me the pun). It can be intermixed with the usual Csound syntax to allow
fantastic unreadability. ;)

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie




------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

I have to disagree that this would make sense.  In this case, C
doesn't have type hinting of functions as the language doesn't have
the ambiguities that arise from polymorphic output, nor does it have
type inference.  The '.' is used as a way to access a member in a
struct in C, and that's really it.  Python doesn't have explicit
types, but there was a proposal for optional static typing by Guido
Van Rossum that used colons that's close in spirit to what's
developing in Csound [1]:

def foo(f: StringIO) -> str:
    f.write("hello")
    return f.getvalue()


(Though, in this proposal it used -> for return types, and : for arg
type specification)

Using colons with types shows up in other languages. The following are
some examples:

Haskell [2] uses two colons:

ghci> 20 :: Int
20
ghci> 20 :: Integer
20
ghci> 20 :: Float
20.0
ghci> 20 :: Double
20.0


Actionscript [3] uses a colon:

var greet:TextField = new TextField();


Scala [4] uses colon:

object HelloWorld {
    def main(args: Array[String]) {
      println("Hello, world!")
    }
  }

Pascal's [5] records have a kind of infix colon type declaration:

  b = record
        x : integer;
        y : char
      end;

OCaml's type expressions[6]:

type pair_of_ints = { a : int; b : int };;

are described in [7].


Regarding the use of '.', I think we should reserve it for accessing
members of data types.  Colons can work well with both type hinting of
opcodes as well as declaring types for variables.  Using '.' on the
other hand would then limit us from having something like:

data Ambi x:k, y:k, z:k, w:k

opcode ambistereo aa, :Ambi
  ambiSig:Ambi xin
... do processing using ambiSig.x, ambiSig.y, ambiSig.z, and ambiSig.w
xout aLeft, aRight
endop



mySig:Ambi  ambiprocess ain, .2, -.2, 0
aLeft, aRight ambistereo mySig


Also, keep in my that advancing the implementation of type inference
is the goal as CS6 evolves, such that the user won't have to enter
types for much of anything, such that the above might look like:

data Ambi x:k, y:k, z:k, w:k

opcode ambistereo aa, :Ambi
 ambiSig xin // use type specified from line above
... do processing using ambiSig.x, ambiSig.y, ambiSig.z, and ambiSig.w
xout aLeft, aRight
endop

mySig  = ambiprocess(ain, .2, -.2, 0)  // function syntax allowing
type inference
aLeft, aRight = ambistereo(mySig)


steven



[1] - http://www.artima.com/weblogs/viewpost.jsp?thread=85551
[2] - http://learnyouahaskell.com/types-and-typeclasses#type-variables
[3] - http://en.wikipedia.org/wiki/ActionScript
[4] - example from http://www.scala-lang.org/node/166, but this
example doesn't do Scala's type system justice.  The use of infix
types is explained in the Scala Language Reference, p25:
http://www.scala-lang.org/docu/files/ScalaReference.pdf.
[5] - http://en.wikipedia.org/wiki/Pascal_(programming_language)#Data_types
[6] - http://mirror.ocamlcore.org/ocaml-tutorial.org/data_types_and_matching.html
[7] - http://caml.inria.fr/pub/docs/manual-ocaml-4.00/language.html

On Sun, May 26, 2013 at 4:45 AM, Andres Cabrera <mantaraya36@gmail.com> wrote:
> Would it make sense to use a dot instead of a colon?
>
> line.k(...)
>
> I would prefer if we pulled Csound syntax closer to C or python when
> possible, rather than away.
>
> Cheers,
> Andrés
>
>
> On Thu, May 23, 2013 at 2:44 AM, Victor Lazzarini <Victor.Lazzarini@nuim.ie>
> wrote:
>>
>> (longish e-mail alert)
>>
>> Steven and I have been developing this function syntax for Csound and I
>> think we reached a point
>> where it can be used with all opcodes with a single output (or multiple
>> optional outputs, but using just a
>> single output). To enable this, we have introduced type annotations.
>>
>> =======================
>> In general type annotation works like this:
>>
>> 1) opcodes with a single output type (k, a etc) can be used with no extra
>> annotations
>>
>> 2) opcodes that have more than one output type (ie, they can be k- or a-
>> rate depending on
>> the type of the output variable etc) may require annotation to select the
>> correct opcode. This
>> has the form of opcode:type.
>>
>> - when there is a default opcode that cannot be used correctly, for
>> instance
>>
>> chnset("hello\n", "hi")
>> prints(chnget("hi"))
>>
>> new alloc for instr 1:
>> INIT ERROR in instr 1: channel already exists with incompatible type
>> #i0     chnget.i        "hi"
>> INIT ERROR in instr 1: printks param 1 was not a "quoted string"
>>         prints  #i0
>>
>> then you need to select the correct type via an annotation
>>
>> chnset("hello\n", "hi")
>> prints(chnget:S("hi"))
>>
>> new alloc for instr 1:
>> hello
>>
>> - when you want a particular opcode that is not the default one for the
>> input types you've
>> asked:
>>
>> out(oscili(oscili(1,1)*1000,440)*linen(1,0.1,p3,0.1))
>>
>> will select a-rate oscili for amplitude modulation, and k-rate linen for
>> envelope(defaults)
>>
>> out(oscili(oscili:k(1,1)*1000,440)*linen:a(1,0.1,p3,0.1))
>>
>> will select k-rate oscili for amplitude modulation, and a-rate linen for
>> envelope.
>>
>> Note that in both cases, the carrier oscillator does not need an
>> annotation because the
>> defaults for the input types are always correct. You can still use the
>> annotation, but it
>> will not make a difference. If the incorrect annotation is used, you will
>> get a syntax error
>> as expected.
>>
>> - finally with opcodes with multiple out args, type annotations are
>> mandatory
>>
>> outs(diskin2("fox.wav",1))
>>
>> error:  Unable to find opcode entry for 'outs' with matching argument
>> types:
>> Found: (null) outs mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
>> Line: 6 Loc: 1
>>
>> is fixed with
>>
>> out(diskin2:a("fox.wav",1))
>>
>> new alloc for instr 1:
>> diskin2: opened '/Users/victor/audio/fox.wav':
>>          44100 Hz, 1 channel(s), 121569 sample frames
>>
>> =================================
>>
>> We are hoping to introduce support for multiple outputs later, but for the
>> moment, this appears to
>> be quite functional (excuse me the pun). It can be intermixed with the
>> usual Csound syntax to allow
>> fantastic unreadability. ;)
>>
>> Dr Victor Lazzarini
>> Senior Lecturer
>> Dept. of Music
>> NUI Maynooth Ireland
>> tel.: +353 1 708 3545
>> Victor dot Lazzarini AT nuim dot ie
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Try New Relic Now & We'll Send You this Cool Shirt
>> New Relic is the only SaaS-based application performance monitoring
>> service
>> that delivers powerful full stack analytics. Optimize and monitor your
>> browser, app, & servers with just a few lines of code. Try New Relic
>> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

The defaults are only operational in the functional syntax. They can be overridden by type annotations.

Note that the defaults only apply to a few opcodes (which can have various forms, depending on in args and

out args, mostly oscillators and envelope generators are in that category)

Generally speaking, oscillators will default to audio-rate whatever their inputs are, and envelopes to k-rate.

If you use type annotations, then you will get what you want at all occasions.

Victor

On 27 May 2013, at 08:49, Oeyvind Brandtsegg wrote:

Thanks for your immense efforts. I see a bright future for Csound due to the modernizing and up-to-dating of the language.

It will probably be a transition period before we become familiar with the new syntax and develop good coding practices.

Now just one question,

Victor says:
"""
out(oscili(oscili(1,1)*1000,440)*linen(1,0.1,p3,0.1))

will select a-rate oscili for amplitude modulation, and k-rate linen for envelope(defaults)

"""

... so are there default output types for each opcode? (perhaps I missed this in earlier discussions, sorry)

It would initially seem to me like a source of confusion and create a need for looking-it-up-in-the-manual-every-time.

Perhaps just something to get used to.

best
Oeyvind

2013/5/26 Steven Yi <stevenyi@gmail.com>

I have to disagree that this would make sense.  In this case, C
doesn't have type hinting of functions as the language doesn't have
the ambiguities that arise from polymorphic output, nor does it have
type inference.  The '.' is used as a way to access a member in a
struct in C, and that's really it.  Python doesn't have explicit
types, but there was a proposal for optional static typing by Guido
Van Rossum that used colons that's close in spirit to what's
developing in Csound [1]:

def foo(f: StringIO) -> str:
    f.write("hello")
    return f.getvalue()


(Though, in this proposal it used -> for return types, and : for arg
type specification)

Using colons with types shows up in other languages. The following are
some examples:

Haskell [2] uses two colons:

ghci> 20 :: Int
20
ghci> 20 :: Integer
20
ghci> 20 :: Float
20.0
ghci> 20 :: Double
20.0


Actionscript [3] uses a colon:

var greet:TextField = new TextField();


Scala [4] uses colon:

object HelloWorld {
    def main(args: Array[String]) {
      println("Hello, world!")
    }
  }

Pascal's [5] records have a kind of infix colon type declaration:

  b = record
        x : integer;
        y : char
      end;

OCaml's type expressions[6]:

type pair_of_ints = { a : int; b : int };;

are described in [7].


Regarding the use of '.', I think we should reserve it for accessing
members of data types.  Colons can work well with both type hinting of
opcodes as well as declaring types for variables.  Using '.' on the
other hand would then limit us from having something like:

data Ambi x:k, y:k, z:k, w:k

opcode ambistereo aa, :Ambi
  ambiSig:Ambi xin
... do processing using ambiSig.x, ambiSig.y, ambiSig.z, and ambiSig.w
xout aLeft, aRight
endop



mySig:Ambi  ambiprocess ain, .2, -.2, 0
aLeft, aRight ambistereo mySig


Also, keep in my that advancing the implementation of type inference
is the goal as CS6 evolves, such that the user won't have to enter
types for much of anything, such that the above might look like:

data Ambi x:k, y:k, z:k, w:k

opcode ambistereo aa, :Ambi
 ambiSig xin // use type specified from line above
... do processing using ambiSig.x, ambiSig.y, ambiSig.z, and ambiSig.w
xout aLeft, aRight
endop

mySig  = ambiprocess(ain, .2, -.2, 0)  // function syntax allowing
type inference
aLeft, aRight = ambistereo(mySig)


steven



[1] - http://www.artima.com/weblogs/viewpost.jsp?thread=85551
[2] - http://learnyouahaskell.com/types-and-typeclasses#type-variables
[3] - http://en.wikipedia.org/wiki/ActionScript
[4] - example from http://www.scala-lang.org/node/166, but this
example doesn't do Scala's type system justice.  The use of infix
types is explained in the Scala Language Reference, p25:
http://www.scala-lang.org/docu/files/ScalaReference.pdf.
[5] - http://en.wikipedia.org/wiki/Pascal_(programming_language)#Data_types
[6] - http://mirror.ocamlcore.org/ocaml-tutorial.org/data_types_and_matching.html
[7] - http://caml.inria.fr/pub/docs/manual-ocaml-4.00/language.html

On Sun, May 26, 2013 at 4:45 AM, Andres Cabrera <mantaraya36@gmail.com> wrote:
> Would it make sense to use a dot instead of a colon?
>
> line.k(...)
>
> I would prefer if we pulled Csound syntax closer to C or python when
> possible, rather than away.
>
> Cheers,
> Andrés
>
>
> On Thu, May 23, 2013 at 2:44 AM, Victor Lazzarini <Victor.Lazzarini@nuim.ie>
> wrote:
>>
>> (longish e-mail alert)
>>
>> Steven and I have been developing this function syntax for Csound and I
>> think we reached a point
>> where it can be used with all opcodes with a single output (or multiple
>> optional outputs, but using just a
>> single output). To enable this, we have introduced type annotations.
>>
>> =======================
>> In general type annotation works like this:
>>
>> 1) opcodes with a single output type (k, a etc) can be used with no extra
>> annotations
>>
>> 2) opcodes that have more than one output type (ie, they can be k- or a-
>> rate depending on
>> the type of the output variable etc) may require annotation to select the
>> correct opcode. This
>> has the form of opcode:type.
>>
>> - when there is a default opcode that cannot be used correctly, for
>> instance
>>
>> chnset("hello\n", "hi")
>> prints(chnget("hi"))
>>
>> new alloc for instr 1:
>> INIT ERROR in instr 1: channel already exists with incompatible type
>> #i0     chnget.i        "hi"
>> INIT ERROR in instr 1: printks param 1 was not a "quoted string"
>>         prints  #i0
>>
>> then you need to select the correct type via an annotation
>>
>> chnset("hello\n", "hi")
>> prints(chnget:S("hi"))
>>
>> new alloc for instr 1:
>> hello
>>
>> - when you want a particular opcode that is not the default one for the
>> input types you've
>> asked:
>>
>> out(oscili(oscili(1,1)*1000,440)*linen(1,0.1,p3,0.1))
>>
>> will select a-rate oscili for amplitude modulation, and k-rate linen for
>> envelope(defaults)
>>
>> out(oscili(oscili:k(1,1)*1000,440)*linen:a(1,0.1,p3,0.1))
>>
>> will select k-rate oscili for amplitude modulation, and a-rate linen for
>> envelope.
>>
>> Note that in both cases, the carrier oscillator does not need an
>> annotation because the
>> defaults for the input types are always correct. You can still use the
>> annotation, but it
>> will not make a difference. If the incorrect annotation is used, you will
>> get a syntax error
>> as expected.
>>
>> - finally with opcodes with multiple out args, type annotations are
>> mandatory
>>
>> outs(diskin2("fox.wav",1))
>>
>> error:  Unable to find opcode entry for 'outs' with matching argument
>> types:
>> Found: (null) outs mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
>> Line: 6 Loc: 1
>>
>> is fixed with
>>
>> out(diskin2:a("fox.wav",1))
>>
>> new alloc for instr 1:
>> diskin2: opened '/Users/victor/audio/fox.wav':
>>          44100 Hz, 1 channel(s), 121569 sample frames
>>
>> =================================
>>
>> We are hoping to introduce support for multiple outputs later, but for the
>> moment, this appears to
>> be quite functional (excuse me the pun). It can be intermixed with the
>> usual Csound syntax to allow
>> fantastic unreadability. ;)
>>
>> Dr Victor Lazzarini
>> Senior Lecturer
>> Dept. of Music
>> NUI Maynooth Ireland
>> tel.: +353 1 708 3545
>> Victor dot Lazzarini AT nuim dot ie
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Try New Relic Now & We'll Send You this Cool Shirt
>> New Relic is the only SaaS-based application performance monitoring
>> service
>> that delivers powerful full stack analytics. Optimize and monitor your
>> browser, app, & servers with just a few lines of code. Try New Relic
>> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

--

Oeyvind Brandtsegg
Professor of Music Technology
NTNU
7491 Trondheim
Norway
Cell: +47 92 203 205

http://flyndresang.no/
http://www.partikkelaudio.com/
http://soundcloud.com/brandtsegg
http://soundcloud.com/t-emp

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

Dr Victor Lazzarini

Senior Lecturer

Dept. of Music

NUI Maynooth Ireland

tel.: +353 1 708 3545

Victor dot Lazzarini AT nuim dot ie

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

I just remembered why k-rate envelopes. They would allow

vco2(linen(...), ...)

since vco2 and some other signal generators only have k-rate inputs. So it's just a matter of whether we 

care to use more or less annotations.

Victor

On 28 May 2013, at 11:43, Oeyvind Brandtsegg wrote:

Excellent, All good.
"Generally speaking, oscillators will default to audio-rate whatever their inputs are, and envelopes to k-rate."

Yes, that is quite easy to remember.

Perhaps it would be even more easy to remember if the default was a-rate for all signal generators?

Or do you think that would clutter the elegant and tight syntax? (needing to specify :k here and there for optimization)

best
Oeyvind

2013/5/27 Victor Lazzarini <Victor.Lazzarini@nuim.ie>

The defaults are only operational in the functional syntax. They can be overridden by type annotations.

Note that the defaults only apply to a few opcodes (which can have various forms, depending on in args and

out args, mostly oscillators and envelope generators are in that category)

Generally speaking, oscillators will default to audio-rate whatever their inputs are, and envelopes to k-rate.

If you use type annotations, then you will get what you want at all occasions.

Victor

On 27 May 2013, at 08:49, Oeyvind Brandtsegg wrote:

Thanks for your immense efforts. I see a bright future for Csound due to the modernizing and up-to-dating of the language.

It will probably be a transition period before we become familiar with the new syntax and develop good coding practices.

Now just one question,

Victor says:
"""
out(oscili(oscili(1,1)*1000,440)*linen(1,0.1,p3,0.1))

will select a-rate oscili for amplitude modulation, and k-rate linen for envelope(defaults)

"""

... so are there default output types for each opcode? (perhaps I missed this in earlier discussions, sorry)

It would initially seem to me like a source of confusion and create a need for looking-it-up-in-the-manual-every-time.

Perhaps just something to get used to.

best
Oeyvind

2013/5/26 Steven Yi <stevenyi@gmail.com>

I have to disagree that this would make sense.  In this case, C
doesn't have type hinting of functions as the language doesn't have
the ambiguities that arise from polymorphic output, nor does it have
type inference.  The '.' is used as a way to access a member in a
struct in C, and that's really it.  Python doesn't have explicit
types, but there was a proposal for optional static typing by Guido
Van Rossum that used colons that's close in spirit to what's
developing in Csound [1]:

def foo(f: StringIO) -> str:
    f.write("hello")
    return f.getvalue()


(Though, in this proposal it used -> for return types, and : for arg
type specification)

Using colons with types shows up in other languages. The following are
some examples:

Haskell [2] uses two colons:

ghci> 20 :: Int
20
ghci> 20 :: Integer
20
ghci> 20 :: Float
20.0
ghci> 20 :: Double
20.0


Actionscript [3] uses a colon:

var greet:TextField = new TextField();


Scala [4] uses colon:

object HelloWorld {
    def main(args: Array[String]) {
      println("Hello, world!")
    }
  }

Pascal's [5] records have a kind of infix colon type declaration:

  b = record
        x : integer;
        y : char
      end;

OCaml's type expressions[6]:

type pair_of_ints = { a : int; b : int };;

are described in [7].


Regarding the use of '.', I think we should reserve it for accessing
members of data types.  Colons can work well with both type hinting of
opcodes as well as declaring types for variables.  Using '.' on the
other hand would then limit us from having something like:

data Ambi x:k, y:k, z:k, w:k

opcode ambistereo aa, :Ambi
  ambiSig:Ambi xin
... do processing using ambiSig.x, ambiSig.y, ambiSig.z, and ambiSig.w
xout aLeft, aRight
endop



mySig:Ambi  ambiprocess ain, .2, -.2, 0
aLeft, aRight ambistereo mySig


Also, keep in my that advancing the implementation of type inference
is the goal as CS6 evolves, such that the user won't have to enter
types for much of anything, such that the above might look like:

data Ambi x:k, y:k, z:k, w:k

opcode ambistereo aa, :Ambi
 ambiSig xin // use type specified from line above
... do processing using ambiSig.x, ambiSig.y, ambiSig.z, and ambiSig.w
xout aLeft, aRight
endop

mySig  = ambiprocess(ain, .2, -.2, 0)  // function syntax allowing
type inference
aLeft, aRight = ambistereo(mySig)


steven



[1] - http://www.artima.com/weblogs/viewpost.jsp?thread=85551
[2] - http://learnyouahaskell.com/types-and-typeclasses#type-variables
[3] - http://en.wikipedia.org/wiki/ActionScript
[4] - example from http://www.scala-lang.org/node/166, but this
example doesn't do Scala's type system justice.  The use of infix
types is explained in the Scala Language Reference, p25:
http://www.scala-lang.org/docu/files/ScalaReference.pdf.
[5] - http://en.wikipedia.org/wiki/Pascal_(programming_language)#Data_types
[6] - http://mirror.ocamlcore.org/ocaml-tutorial.org/data_types_and_matching.html
[7] - http://caml.inria.fr/pub/docs/manual-ocaml-4.00/language.html

On Sun, May 26, 2013 at 4:45 AM, Andres Cabrera <mantaraya36@gmail.com> wrote:
> Would it make sense to use a dot instead of a colon?
>
> line.k(...)
>
> I would prefer if we pulled Csound syntax closer to C or python when
> possible, rather than away.
>
> Cheers,
> Andrés
>
>
> On Thu, May 23, 2013 at 2:44 AM, Victor Lazzarini <Victor.Lazzarini@nuim.ie>
> wrote:
>>
>> (longish e-mail alert)
>>
>> Steven and I have been developing this function syntax for Csound and I
>> think we reached a point
>> where it can be used with all opcodes with a single output (or multiple
>> optional outputs, but using just a
>> single output). To enable this, we have introduced type annotations.
>>
>> =======================
>> In general type annotation works like this:
>>
>> 1) opcodes with a single output type (k, a etc) can be used with no extra
>> annotations
>>
>> 2) opcodes that have more than one output type (ie, they can be k- or a-
>> rate depending on
>> the type of the output variable etc) may require annotation to select the
>> correct opcode. This
>> has the form of opcode:type.
>>
>> - when there is a default opcode that cannot be used correctly, for
>> instance
>>
>> chnset("hello\n", "hi")
>> prints(chnget("hi"))
>>
>> new alloc for instr 1:
>> INIT ERROR in instr 1: channel already exists with incompatible type
>> #i0     chnget.i        "hi"
>> INIT ERROR in instr 1: printks param 1 was not a "quoted string"
>>         prints  #i0
>>
>> then you need to select the correct type via an annotation
>>
>> chnset("hello\n", "hi")
>> prints(chnget:S("hi"))
>>
>> new alloc for instr 1:
>> hello
>>
>> - when you want a particular opcode that is not the default one for the
>> input types you've
>> asked:
>>
>> out(oscili(oscili(1,1)*1000,440)*linen(1,0.1,p3,0.1))
>>
>> will select a-rate oscili for amplitude modulation, and k-rate linen for
>> envelope(defaults)
>>
>> out(oscili(oscili:k(1,1)*1000,440)*linen:a(1,0.1,p3,0.1))
>>
>> will select k-rate oscili for amplitude modulation, and a-rate linen for
>> envelope.
>>
>> Note that in both cases, the carrier oscillator does not need an
>> annotation because the
>> defaults for the input types are always correct. You can still use the
>> annotation, but it
>> will not make a difference. If the incorrect annotation is used, you will
>> get a syntax error
>> as expected.
>>
>> - finally with opcodes with multiple out args, type annotations are
>> mandatory
>>
>> outs(diskin2("fox.wav",1))
>>
>> error:  Unable to find opcode entry for 'outs' with matching argument
>> types:
>> Found: (null) outs mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
>> Line: 6 Loc: 1
>>
>> is fixed with
>>
>> out(diskin2:a("fox.wav",1))
>>
>> new alloc for instr 1:
>> diskin2: opened '/Users/victor/audio/fox.wav':
>>          44100 Hz, 1 channel(s), 121569 sample frames
>>
>> =================================
>>
>> We are hoping to introduce support for multiple outputs later, but for the
>> moment, this appears to
>> be quite functional (excuse me the pun). It can be intermixed with the
>> usual Csound syntax to allow
>> fantastic unreadability. ;)
>>
>> Dr Victor Lazzarini
>> Senior Lecturer
>> Dept. of Music
>> NUI Maynooth Ireland
>> tel.: +353 1 708 3545
>> Victor dot Lazzarini AT nuim dot ie
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Try New Relic Now & We'll Send You this Cool Shirt
>> New Relic is the only SaaS-based application performance monitoring
>> service
>> that delivers powerful full stack analytics. Optimize and monitor your
>> browser, app, & servers with just a few lines of code. Try New Relic
>> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

--

Oeyvind Brandtsegg
Professor of Music Technology
NTNU
7491 Trondheim
Norway
Cell: +47 92 203 205

http://flyndresang.no/
http://www.partikkelaudio.com/
http://soundcloud.com/brandtsegg
http://soundcloud.com/t-emp

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

Dr Victor Lazzarini

Senior Lecturer

Dept. of Music

NUI Maynooth Ireland

tel.: +353 1 708 3545

Victor dot Lazzarini AT nuim dot ie

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

--

Oeyvind Brandtsegg
Professor of Music Technology
NTNU
7491 Trondheim
Norway
Cell: +47 92 203 205

http://flyndresang.no/
http://www.partikkelaudio.com/
http://soundcloud.com/brandtsegg
http://soundcloud.com/t-emp

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

Dr Victor Lazzarini

Senior Lecturer

Dept. of Music

NUI Maynooth Ireland

tel.: +353 1 708 3545

Victor dot Lazzarini AT nuim dot ie

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

I have to disagree that this would make sense.  In this case, C
doesn't have type hinting of functions as the language doesn't have
the ambiguities that arise from polymorphic output, nor does it have
type inference.  The '.' is used as a way to access a member in a
struct in C, and that's really it.  Python doesn't have explicit
types, but there was a proposal for optional static typing by Guido
Van Rossum that used colons that's close in spirit to what's
developing in Csound [1]:

def foo(f: StringIO) -> str:
    f.write("hello")
    return f.getvalue()


(Though, in this proposal it used -> for return types, and : for arg
type specification)

Using colons with types shows up in other languages. The following are
some examples:

Haskell [2] uses two colons:

ghci> 20 :: Int
20
ghci> 20 :: Integer
20
ghci> 20 :: Float
20.0
ghci> 20 :: Double
20.0


Actionscript [3] uses a colon:

var greet:TextField = new TextField();


Scala [4] uses colon:

object HelloWorld {
    def main(args: Array[String]) {
      println("Hello, world!")
    }
  }

Pascal's [5] records have a kind of infix colon type declaration:

  b = record
        x : integer;
        y : char
      end;

OCaml's type expressions[6]:

type pair_of_ints = { a : int; b : int };;

are described in [7].


Regarding the use of '.', I think we should reserve it for accessing
members of data types.  Colons can work well with both type hinting of
opcodes as well as declaring types for variables.  Using '.' on the
other hand would then limit us from having something like:

data Ambi x:k, y:k, z:k, w:k

opcode ambistereo aa, :Ambi
  ambiSig:Ambi xin
... do processing using ambiSig.x, ambiSig.y, ambiSig.z, and ambiSig.w
xout aLeft, aRight
endop



mySig:Ambi  ambiprocess ain, .2, -.2, 0
aLeft, aRight ambistereo mySig


Also, keep in my that advancing the implementation of type inference
is the goal as CS6 evolves, such that the user won't have to enter
types for much of anything, such that the above might look like:

data Ambi x:k, y:k, z:k, w:k

opcode ambistereo aa, :Ambi
 ambiSig xin // use type specified from line above
... do processing using ambiSig.x, ambiSig.y, ambiSig.z, and ambiSig.w
xout aLeft, aRight
endop

mySig  = ambiprocess(ain, .2, -.2, 0)  // function syntax allowing
type inference
aLeft, aRight = ambistereo(mySig)


steven



[1] - http://www.artima.com/weblogs/viewpost.jsp?thread=85551
[2] - http://learnyouahaskell.com/types-and-typeclasses#type-variables
[3] - http://en.wikipedia.org/wiki/ActionScript
[4] - example from http://www.scala-lang.org/node/166, but this
example doesn't do Scala's type system justice.  The use of infix
types is explained in the Scala Language Reference, p25:
http://www.scala-lang.org/docu/files/ScalaReference.pdf.
[5] - http://en.wikipedia.org/wiki/Pascal_(programming_language)#Data_types
[6] - http://mirror.ocamlcore.org/ocaml-tutorial.org/data_types_and_matching.html
[7] - http://caml.inria.fr/pub/docs/manual-ocaml-4.00/language.html

On Sun, May 26, 2013 at 4:45 AM, Andres Cabrera <mantaraya36@gmail.com> wrote:
> Would it make sense to use a dot instead of a colon?
>
> line.k(...)
>
> I would prefer if we pulled Csound syntax closer to C or python when
> possible, rather than away.
>
> Cheers,
> Andrés
>
>
> On Thu, May 23, 2013 at 2:44 AM, Victor Lazzarini <Victor.Lazzarini@nuim.ie>
> wrote:
>>
>> (longish e-mail alert)
>>
>> Steven and I have been developing this function syntax for Csound and I
>> think we reached a point
>> where it can be used with all opcodes with a single output (or multiple
>> optional outputs, but using just a
>> single output). To enable this, we have introduced type annotations.
>>
>> =======================
>> In general type annotation works like this:
>>
>> 1) opcodes with a single output type (k, a etc) can be used with no extra
>> annotations
>>
>> 2) opcodes that have more than one output type (ie, they can be k- or a-
>> rate depending on
>> the type of the output variable etc) may require annotation to select the
>> correct opcode. This
>> has the form of opcode:type.
>>
>> - when there is a default opcode that cannot be used correctly, for
>> instance
>>
>> chnset("hello\n", "hi")
>> prints(chnget("hi"))
>>
>> new alloc for instr 1:
>> INIT ERROR in instr 1: channel already exists with incompatible type
>> #i0     chnget.i        "hi"
>> INIT ERROR in instr 1: printks param 1 was not a "quoted string"
>>         prints  #i0
>>
>> then you need to select the correct type via an annotation
>>
>> chnset("hello\n", "hi")
>> prints(chnget:S("hi"))
>>
>> new alloc for instr 1:
>> hello
>>
>> - when you want a particular opcode that is not the default one for the
>> input types you've
>> asked:
>>
>> out(oscili(oscili(1,1)*1000,440)*linen(1,0.1,p3,0.1))
>>
>> will select a-rate oscili for amplitude modulation, and k-rate linen for
>> envelope(defaults)
>>
>> out(oscili(oscili:k(1,1)*1000,440)*linen:a(1,0.1,p3,0.1))
>>
>> will select k-rate oscili for amplitude modulation, and a-rate linen for
>> envelope.
>>
>> Note that in both cases, the carrier oscillator does not need an
>> annotation because the
>> defaults for the input types are always correct. You can still use the
>> annotation, but it
>> will not make a difference. If the incorrect annotation is used, you will
>> get a syntax error
>> as expected.
>>
>> - finally with opcodes with multiple out args, type annotations are
>> mandatory
>>
>> outs(diskin2("fox.wav",1))
>>
>> error:  Unable to find opcode entry for 'outs' with matching argument
>> types:
>> Found: (null) outs mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
>> Line: 6 Loc: 1
>>
>> is fixed with
>>
>> out(diskin2:a("fox.wav",1))
>>
>> new alloc for instr 1:
>> diskin2: opened '/Users/victor/audio/fox.wav':
>>          44100 Hz, 1 channel(s), 121569 sample frames
>>
>> =================================
>>
>> We are hoping to introduce support for multiple outputs later, but for the
>> moment, this appears to
>> be quite functional (excuse me the pun). It can be intermixed with the
>> usual Csound syntax to allow
>> fantastic unreadability. ;)
>>
>> Dr Victor Lazzarini
>> Senior Lecturer
>> Dept. of Music
>> NUI Maynooth Ireland
>> tel.: +353 1 708 3545
>> Victor dot Lazzarini AT nuim dot ie
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Try New Relic Now & We'll Send You this Cool Shirt
>> New Relic is the only SaaS-based application performance monitoring
>> service
>> that delivers powerful full stack analytics. Optimize and monitor your
>> browser, app, & servers with just a few lines of code. Try New Relic
>> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

No, it doesn't work like that, because we don't have type inference, which means we don't know what the input is asking for.

That is why we need to annotate. If we had a good guess of what vco2() etc required, it would all be automatic. That is the goal (type inference),

but we are not there quite yet. The type annotations allow us to use the functional syntax for polymorphic (if they weren't there it, we

would only have the defaults, and also some opcodes would not pass semantic/syntactic tests).

Victor

On 28 May 2013, at 14:41, Oeyvind Brandtsegg wrote:

aha :-)

Maybe the default could be the highest possible rate for the input it is being used to drive?

(hope I'm not being difficult... :-)

Oeyvind

2013/5/28 Victor Lazzarini <Victor.Lazzarini@nuim.ie>

I just remembered why k-rate envelopes. They would allow

vco2(linen(...), ...)

since vco2 and some other signal generators only have k-rate inputs. So it's just a matter of whether we 

care to use more or less annotations.

Victor

On 28 May 2013, at 11:43, Oeyvind Brandtsegg wrote:

Excellent, All good.
"Generally speaking, oscillators will default to audio-rate whatever their inputs are, and envelopes to k-rate."

Yes, that is quite easy to remember.

Perhaps it would be even more easy to remember if the default was a-rate for all signal generators?

Or do you think that would clutter the elegant and tight syntax? (needing to specify :k here and there for optimization)

best
Oeyvind

2013/5/27 Victor Lazzarini <Victor.Lazzarini@nuim.ie>

The defaults are only operational in the functional syntax. They can be overridden by type annotations.

Note that the defaults only apply to a few opcodes (which can have various forms, depending on in args and

out args, mostly oscillators and envelope generators are in that category)

Generally speaking, oscillators will default to audio-rate whatever their inputs are, and envelopes to k-rate.

If you use type annotations, then you will get what you want at all occasions.

Victor

On 27 May 2013, at 08:49, Oeyvind Brandtsegg wrote:

Thanks for your immense efforts. I see a bright future for Csound due to the modernizing and up-to-dating of the language.

It will probably be a transition period before we become familiar with the new syntax and develop good coding practices.

Now just one question,

Victor says:
"""
out(oscili(oscili(1,1)*1000,440)*linen(1,0.1,p3,0.1))

will select a-rate oscili for amplitude modulation, and k-rate linen for envelope(defaults)

"""

... so are there default output types for each opcode? (perhaps I missed this in earlier discussions, sorry)

It would initially seem to me like a source of confusion and create a need for looking-it-up-in-the-manual-every-time.

Perhaps just something to get used to.

best
Oeyvind

2013/5/26 Steven Yi <stevenyi@gmail.com>

I have to disagree that this would make sense.  In this case, C
doesn't have type hinting of functions as the language doesn't have
the ambiguities that arise from polymorphic output, nor does it have
type inference.  The '.' is used as a way to access a member in a
struct in C, and that's really it.  Python doesn't have explicit
types, but there was a proposal for optional static typing by Guido
Van Rossum that used colons that's close in spirit to what's
developing in Csound [1]:

def foo(f: StringIO) -> str:
    f.write("hello")
    return f.getvalue()


(Though, in this proposal it used -> for return types, and : for arg
type specification)

Using colons with types shows up in other languages. The following are
some examples:

Haskell [2] uses two colons:

ghci> 20 :: Int
20
ghci> 20 :: Integer
20
ghci> 20 :: Float
20.0
ghci> 20 :: Double
20.0


Actionscript [3] uses a colon:

var greet:TextField = new TextField();


Scala [4] uses colon:

object HelloWorld {
    def main(args: Array[String]) {
      println("Hello, world!")
    }
  }

Pascal's [5] records have a kind of infix colon type declaration:

  b = record
        x : integer;
        y : char
      end;

OCaml's type expressions[6]:

type pair_of_ints = { a : int; b : int };;

are described in [7].


Regarding the use of '.', I think we should reserve it for accessing
members of data types.  Colons can work well with both type hinting of
opcodes as well as declaring types for variables.  Using '.' on the
other hand would then limit us from having something like:

data Ambi x:k, y:k, z:k, w:k

opcode ambistereo aa, :Ambi
  ambiSig:Ambi xin
... do processing using ambiSig.x, ambiSig.y, ambiSig.z, and ambiSig.w
xout aLeft, aRight
endop



mySig:Ambi  ambiprocess ain, .2, -.2, 0
aLeft, aRight ambistereo mySig


Also, keep in my that advancing the implementation of type inference
is the goal as CS6 evolves, such that the user won't have to enter
types for much of anything, such that the above might look like:

data Ambi x:k, y:k, z:k, w:k

opcode ambistereo aa, :Ambi
 ambiSig xin // use type specified from line above
... do processing using ambiSig.x, ambiSig.y, ambiSig.z, and ambiSig.w
xout aLeft, aRight
endop

mySig  = ambiprocess(ain, .2, -.2, 0)  // function syntax allowing
type inference
aLeft, aRight = ambistereo(mySig)


steven



[1] - http://www.artima.com/weblogs/viewpost.jsp?thread=85551
[2] - http://learnyouahaskell.com/types-and-typeclasses#type-variables
[3] - http://en.wikipedia.org/wiki/ActionScript
[4] - example from http://www.scala-lang.org/node/166, but this
example doesn't do Scala's type system justice.  The use of infix
types is explained in the Scala Language Reference, p25:
http://www.scala-lang.org/docu/files/ScalaReference.pdf.
[5] - http://en.wikipedia.org/wiki/Pascal_(programming_language)#Data_types
[6] - http://mirror.ocamlcore.org/ocaml-tutorial.org/data_types_and_matching.html
[7] - http://caml.inria.fr/pub/docs/manual-ocaml-4.00/language.html

On Sun, May 26, 2013 at 4:45 AM, Andres Cabrera <mantaraya36@gmail.com> wrote:
> Would it make sense to use a dot instead of a colon?
>
> line.k(...)
>
> I would prefer if we pulled Csound syntax closer to C or python when
> possible, rather than away.
>
> Cheers,
> Andrés
>
>
> On Thu, May 23, 2013 at 2:44 AM, Victor Lazzarini <Victor.Lazzarini@nuim.ie>
> wrote:
>>
>> (longish e-mail alert)
>>
>> Steven and I have been developing this function syntax for Csound and I
>> think we reached a point
>> where it can be used with all opcodes with a single output (or multiple
>> optional outputs, but using just a
>> single output). To enable this, we have introduced type annotations.
>>
>> =======================
>> In general type annotation works like this:
>>
>> 1) opcodes with a single output type (k, a etc) can be used with no extra
>> annotations
>>
>> 2) opcodes that have more than one output type (ie, they can be k- or a-
>> rate depending on
>> the type of the output variable etc) may require annotation to select the
>> correct opcode. This
>> has the form of opcode:type.
>>
>> - when there is a default opcode that cannot be used correctly, for
>> instance
>>
>> chnset("hello\n", "hi")
>> prints(chnget("hi"))
>>
>> new alloc for instr 1:
>> INIT ERROR in instr 1: channel already exists with incompatible type
>> #i0     chnget.i        "hi"
>> INIT ERROR in instr 1: printks param 1 was not a "quoted string"
>>         prints  #i0
>>
>> then you need to select the correct type via an annotation
>>
>> chnset("hello\n", "hi")
>> prints(chnget:S("hi"))
>>
>> new alloc for instr 1:
>> hello
>>
>> - when you want a particular opcode that is not the default one for the
>> input types you've
>> asked:
>>
>> out(oscili(oscili(1,1)*1000,440)*linen(1,0.1,p3,0.1))
>>
>> will select a-rate oscili for amplitude modulation, and k-rate linen for
>> envelope(defaults)
>>
>> out(oscili(oscili:k(1,1)*1000,440)*linen:a(1,0.1,p3,0.1))
>>
>> will select k-rate oscili for amplitude modulation, and a-rate linen for
>> envelope.
>>
>> Note that in both cases, the carrier oscillator does not need an
>> annotation because the
>> defaults for the input types are always correct. You can still use the
>> annotation, but it
>> will not make a difference. If the incorrect annotation is used, you will
>> get a syntax error
>> as expected.
>>
>> - finally with opcodes with multiple out args, type annotations are
>> mandatory
>>
>> outs(diskin2("fox.wav",1))
>>
>> error:  Unable to find opcode entry for 'outs' with matching argument
>> types:
>> Found: (null) outs mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
>> Line: 6 Loc: 1
>>
>> is fixed with
>>
>> out(diskin2:a("fox.wav",1))
>>
>> new alloc for instr 1:
>> diskin2: opened '/Users/victor/audio/fox.wav':
>>          44100 Hz, 1 channel(s), 121569 sample frames
>>
>> =================================
>>
>> We are hoping to introduce support for multiple outputs later, but for the
>> moment, this appears to
>> be quite functional (excuse me the pun). It can be intermixed with the
>> usual Csound syntax to allow
>> fantastic unreadability. ;)
>>
>> Dr Victor Lazzarini
>> Senior Lecturer
>> Dept. of Music
>> NUI Maynooth Ireland
>> tel.: +353 1 708 3545
>> Victor dot Lazzarini AT nuim dot ie
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Try New Relic Now & We'll Send You this Cool Shirt
>> New Relic is the only SaaS-based application performance monitoring
>> service
>> that delivers powerful full stack analytics. Optimize and monitor your
>> browser, app, & servers with just a few lines of code. Try New Relic
>> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

--

Oeyvind Brandtsegg
Professor of Music Technology
NTNU
7491 Trondheim
Norway
Cell: +47 92 203 205

http://flyndresang.no/
http://www.partikkelaudio.com/
http://soundcloud.com/brandtsegg
http://soundcloud.com/t-emp

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

Dr Victor Lazzarini

Senior Lecturer

Dept. of Music

NUI Maynooth Ireland

tel.: +353 1 708 3545

Victor dot Lazzarini AT nuim dot ie

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

--

Oeyvind Brandtsegg
Professor of Music Technology
NTNU
7491 Trondheim
Norway
Cell: +47 92 203 205

http://flyndresang.no/
http://www.partikkelaudio.com/
http://soundcloud.com/brandtsegg
http://soundcloud.com/t-emp

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

Dr Victor Lazzarini

Senior Lecturer

Dept. of Music

NUI Maynooth Ireland

tel.: +353 1 708 3545

Victor dot Lazzarini AT nuim dot ie

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

--

Oeyvind Brandtsegg
Professor of Music Technology
NTNU
7491 Trondheim
Norway
Cell: +47 92 203 205

http://flyndresang.no/
http://www.partikkelaudio.com/
http://soundcloud.com/brandtsegg
http://soundcloud.com/t-emp

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

Dr Victor Lazzarini

Senior Lecturer

Dept. of Music

NUI Maynooth Ireland

tel.: +353 1 708 3545

Victor dot Lazzarini AT nuim dot ie

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel