Hi All,

Just a status update: I'm slowly catching up after moving and did some
exploratory work today for two things, explicit typing and runtime
type identification. For explicit typing, which would be explicitly
saying what type a variable is using something like:

myAudioSig:a = vco2(440, 0.5)
outs myAudioSig, myAudioSig

I ran into a lexer/parser problem where myAudioSig:a gets parsed as a
label then an unexpected "a".  I think for now I will table this item
as this would be simpler to deal with using an updated lexer/parser
("Parser3").

For RTTI, I think I have sorted out what needs to be done.  Currently
there are the following arg types for opcodes:

Pfield
Local
Global
String Constant
Float Constant
Label

To deal with each of these, I think the solution is to use this struct:

typedef struct csvarmem {
        CS_TYPE* varType;
        MYFLT memBlock;
    } CS_VAR_MEM;

the struct would be used more for casting a block of memory rather
than directly allocating.  For example, if we were going to store a
STRINGDAT, we could have code like:

CS_VAR_MEM* varMem = csound->Calloc(csound, sizeof(STRINGDAT) +
sizeof(CS_TYPE*));
varMem->varType = &CS_VAR_TYPE_S;
...do code that uses varMem->memBlock...

and this kind of patter would replace only allocating
sizeof(STRINGDAT) or whatever var type is there.

I think using this, plus modifying CS_VARIABLE to move the CS_TYPE*
varType member to just before the memBlock pointer (in
include/csound_type_system.h), this would work for all of the arg
types.  (This would require a version bump.)

With the type information made available, we should be able to do a
few interesting things. One, for any arg pointer, we could just
subtract sizeof(CS_TYPE*) to look up the type of the arg.  This means
we could get rid of things like xincod and xincod_str, which are sort
of hackish IMO.  We could also use this to do type checking for
pfields, which later opens up possibilities for sending more than just
strings and numbers in events.

I'm going to continue looking into the runtime type stuff for the next
few days and will email any updates.

Thanks!
steven

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

hi steven -

these are exciting explorations. having explicit typing would make a lot 
of code much more readable, and it would be good for beginners to know: 
"i must declare the type of a variable at its first usage."

so, hopefully parser3 is not too far.

thanks and all best -

	joachim


Am 01.07.2014 23:36, schrieb Steven Yi:
> Hi All,
>
> Just a status update: I'm slowly catching up after moving and did some
> exploratory work today for two things, explicit typing and runtime
> type identification. For explicit typing, which would be explicitly
> saying what type a variable is using something like:
>
> myAudioSig:a = vco2(440, 0.5)
> outs myAudioSig, myAudioSig
>
> I ran into a lexer/parser problem where myAudioSig:a gets parsed as a
> label then an unexpected "a".  I think for now I will table this item
> as this would be simpler to deal with using an updated lexer/parser
> ("Parser3").
>
> For RTTI, I think I have sorted out what needs to be done.  Currently
> there are the following arg types for opcodes:
>
> Pfield
> Local
> Global
> String Constant
> Float Constant
> Label
>
> To deal with each of these, I think the solution is to use this struct:
>
> typedef struct csvarmem {
>          CS_TYPE* varType;
>          MYFLT memBlock;
>      } CS_VAR_MEM;
>
> the struct would be used more for casting a block of memory rather
> than directly allocating.  For example, if we were going to store a
> STRINGDAT, we could have code like:
>
> CS_VAR_MEM* varMem = csound->Calloc(csound, sizeof(STRINGDAT) +
> sizeof(CS_TYPE*));
> varMem->varType = &CS_VAR_TYPE_S;
> ...do code that uses varMem->memBlock...
>
> and this kind of patter would replace only allocating
> sizeof(STRINGDAT) or whatever var type is there.
>
> I think using this, plus modifying CS_VARIABLE to move the CS_TYPE*
> varType member to just before the memBlock pointer (in
> include/csound_type_system.h), this would work for all of the arg
> types.  (This would require a version bump.)
>
> With the type information made available, we should be able to do a
> few interesting things. One, for any arg pointer, we could just
> subtract sizeof(CS_TYPE*) to look up the type of the arg.  This means
> we could get rid of things like xincod and xincod_str, which are sort
> of hackish IMO.  We could also use this to do type checking for
> pfields, which later opens up possibilities for sending more than just
> strings and numbers in events.
>
> I'm going to continue looking into the runtime type stuff for the next
> few days and will email any updates.
>
> Thanks!
> steven
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Joachim,

Thanks!  Regarding explicit typing, I'd just mention that it's a
necessary thing to enable user-defined types. Beyond that,
implementing a formal type inference system would reduce the need to
explicitly type a variable. So the steps should be:

1. enable explicit typing for existing types:

myVar:a = vco2(440, 0.5)

2. implement user-defined types:

data AmbiSig w:a,
  x:a
  y:a
  z:a
end

myVar:AmbiSig = AmbiSig(0, 0.5, 0.3, 0.2)

(the above is just an example I thought up, could be done differently)

3. implement formal type inference:

; may require some explicit typing for opcodes with polymorphic out
types, but below assumes the type of myVar can be determined by later
usage of the var
myVar = vco2(440, 0.5)

data AmbiSig w:a,
  x:a
  y:a
  z:a
end

myVar2 = AmbiSig(0, 0.5, 0.3, 0.2)


That basically covers the game plan I've got in mind.

Also just as an update, I think that the change to CS_VARIABLE is not
necessary and wouldn't work actually as memBlock is a pointer.  The
change for that then is to store CS_VAR_MEM as the memBlock pointer
instead of void*.  This would actually work just fine and I think
would be a backwards compatible change.  I've started work on
implementing the RTTI, and have so far implemented this for number
constants.  I'm making my way through each arg type and will next
report when things are implemented or if there is any serious blocks.

Thanks!
steven


On Wed, Jul 2, 2014 at 2:51 PM, joachim heintz  wrote:
> hi steven -
>
> these are exciting explorations. having explicit typing would make a lot
> of code much more readable, and it would be good for beginners to know:
> "i must declare the type of a variable at its first usage."
>
> so, hopefully parser3 is not too far.
>
> thanks and all best -
>
>         joachim
>
>
> Am 01.07.2014 23:36, schrieb Steven Yi:
>> Hi All,
>>
>> Just a status update: I'm slowly catching up after moving and did some
>> exploratory work today for two things, explicit typing and runtime
>> type identification. For explicit typing, which would be explicitly
>> saying what type a variable is using something like:
>>
>> myAudioSig:a = vco2(440, 0.5)
>> outs myAudioSig, myAudioSig
>>
>> I ran into a lexer/parser problem where myAudioSig:a gets parsed as a
>> label then an unexpected "a".  I think for now I will table this item
>> as this would be simpler to deal with using an updated lexer/parser
>> ("Parser3").
>>
>> For RTTI, I think I have sorted out what needs to be done.  Currently
>> there are the following arg types for opcodes:
>>
>> Pfield
>> Local
>> Global
>> String Constant
>> Float Constant
>> Label
>>
>> To deal with each of these, I think the solution is to use this struct:
>>
>> typedef struct csvarmem {
>>          CS_TYPE* varType;
>>          MYFLT memBlock;
>>      } CS_VAR_MEM;
>>
>> the struct would be used more for casting a block of memory rather
>> than directly allocating.  For example, if we were going to store a
>> STRINGDAT, we could have code like:
>>
>> CS_VAR_MEM* varMem = csound->Calloc(csound, sizeof(STRINGDAT) +
>> sizeof(CS_TYPE*));
>> varMem->varType = &CS_VAR_TYPE_S;
>> ...do code that uses varMem->memBlock...
>>
>> and this kind of patter would replace only allocating
>> sizeof(STRINGDAT) or whatever var type is there.
>>
>> I think using this, plus modifying CS_VARIABLE to move the CS_TYPE*
>> varType member to just before the memBlock pointer (in
>> include/csound_type_system.h), this would work for all of the arg
>> types.  (This would require a version bump.)
>>
>> With the type information made available, we should be able to do a
>> few interesting things. One, for any arg pointer, we could just
>> subtract sizeof(CS_TYPE*) to look up the type of the arg.  This means
>> we could get rid of things like xincod and xincod_str, which are sort
>> of hackish IMO.  We could also use this to do type checking for
>> pfields, which later opens up possibilities for sending more than just
>> strings and numbers in events.
>>
>> I'm going to continue looking into the runtime type stuff for the next
>> few days and will email any updates.
>>
>> Thanks!
>> steven
>>
>> ------------------------------------------------------------------------------
>> Open source business process management suite built on Java and Eclipse
>> Turn processes into business applications with Bonita BPM Community Edition
>> Quickly connect people, data, and systems into organized workflows
>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>> http://p.sf.net/sfu/Bonitasoft
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I think the cost is pretty minimal for both performance and memory.
For space, it adds the sizeof(CS_TYPE*) for all vars and constants.
For time, it has to assign the type.  The additional work depends a
bit on the number of variables that exist in an instrument or
globally. I haven't done any proper benchmarks though.

Just FYI, I have the type stuff working for global vars, local vars,
string constants, and float constants. I need to do labels and pfields
next, then check if this affects UDO args.

To note, the following test code:

gi_var = 22
gk_var = 33
gS_var = "TEST"

instr 1

prints "Testing constants...\n"
print_type 44
print_type "test"

prints "Testing Global Vars...\n"
print_type gi_var
print_type gk_var
print_type gS_var

ivar = 300
kvar = 400
avar init 0

prints "Testing Local Vars...\n"
print_type ivar
print_type kvar
print_type avar

turnoff

endin

currently prints:

Testing constants...
Variable Type: c
Variable Type: S
Testing Global Vars...
Variable Type: i
Variable Type: k
Variable Type: S
Testing Local Vars...
Variable Type: i
Variable Type: k
Variable Type: a

There is a bit of a discrepency here with the constants.  We don't
have a const string type, just String, but we do have the c type,
which is essentially a const double.  The setting of the type though
can be easily changed though, so we can work that out later.  (Though,
I'd argue that constants are sort of modifier of a type rather than a
type in and of itself...)

On Thu, Jul 3, 2014 at 7:44 PM, Andres Cabrera  wrote:
> This is great, thanks. Do you think there would be a performance penalty? Or
> would things be optimized by the compiler?
>
> Cheers,
> Andrés
>
>
> On Thu, Jul 3, 2014 at 9:09 AM, Steven Yi  wrote:
>>
>> Hi Joachim,
>>
>> Thanks!  Regarding explicit typing, I'd just mention that it's a
>> necessary thing to enable user-defined types. Beyond that,
>> implementing a formal type inference system would reduce the need to
>> explicitly type a variable. So the steps should be:
>>
>> 1. enable explicit typing for existing types:
>>
>> myVar:a = vco2(440, 0.5)
>>
>> 2. implement user-defined types:
>>
>> data AmbiSig w:a,
>>   x:a
>>   y:a
>>   z:a
>> end
>>
>> myVar:AmbiSig = AmbiSig(0, 0.5, 0.3, 0.2)
>>
>> (the above is just an example I thought up, could be done differently)
>>
>> 3. implement formal type inference:
>>
>> ; may require some explicit typing for opcodes with polymorphic out
>> types, but below assumes the type of myVar can be determined by later
>> usage of the var
>> myVar = vco2(440, 0.5)
>>
>> data AmbiSig w:a,
>>   x:a
>>   y:a
>>   z:a
>> end
>>
>> myVar2 = AmbiSig(0, 0.5, 0.3, 0.2)
>>
>>
>> That basically covers the game plan I've got in mind.
>>
>> Also just as an update, I think that the change to CS_VARIABLE is not
>> necessary and wouldn't work actually as memBlock is a pointer.  The
>> change for that then is to store CS_VAR_MEM as the memBlock pointer
>> instead of void*.  This would actually work just fine and I think
>> would be a backwards compatible change.  I've started work on
>> implementing the RTTI, and have so far implemented this for number
>> constants.  I'm making my way through each arg type and will next
>> report when things are implemented or if there is any serious blocks.
>>
>> Thanks!
>> steven
>>
>>
>> On Wed, Jul 2, 2014 at 2:51 PM, joachim heintz 
>> wrote:
>> > hi steven -
>> >
>> > these are exciting explorations. having explicit typing would make a lot
>> > of code much more readable, and it would be good for beginners to know:
>> > "i must declare the type of a variable at its first usage."
>> >
>> > so, hopefully parser3 is not too far.
>> >
>> > thanks and all best -
>> >
>> >         joachim
>> >
>> >
>> > Am 01.07.2014 23:36, schrieb Steven Yi:
>> >> Hi All,
>> >>
>> >> Just a status update: I'm slowly catching up after moving and did some
>> >> exploratory work today for two things, explicit typing and runtime
>> >> type identification. For explicit typing, which would be explicitly
>> >> saying what type a variable is using something like:
>> >>
>> >> myAudioSig:a = vco2(440, 0.5)
>> >> outs myAudioSig, myAudioSig
>> >>
>> >> I ran into a lexer/parser problem where myAudioSig:a gets parsed as a
>> >> label then an unexpected "a".  I think for now I will table this item
>> >> as this would be simpler to deal with using an updated lexer/parser
>> >> ("Parser3").
>> >>
>> >> For RTTI, I think I have sorted out what needs to be done.  Currently
>> >> there are the following arg types for opcodes:
>> >>
>> >> Pfield
>> >> Local
>> >> Global
>> >> String Constant
>> >> Float Constant
>> >> Label
>> >>
>> >> To deal with each of these, I think the solution is to use this struct:
>> >>
>> >> typedef struct csvarmem {
>> >>          CS_TYPE* varType;
>> >>          MYFLT memBlock;
>> >>      } CS_VAR_MEM;
>> >>
>> >> the struct would be used more for casting a block of memory rather
>> >> than directly allocating.  For example, if we were going to store a
>> >> STRINGDAT, we could have code like:
>> >>
>> >> CS_VAR_MEM* varMem = csound->Calloc(csound, sizeof(STRINGDAT) +
>> >> sizeof(CS_TYPE*));
>> >> varMem->varType = &CS_VAR_TYPE_S;
>> >> ...do code that uses varMem->memBlock...
>> >>
>> >> and this kind of patter would replace only allocating
>> >> sizeof(STRINGDAT) or whatever var type is there.
>> >>
>> >> I think using this, plus modifying CS_VARIABLE to move the CS_TYPE*
>> >> varType member to just before the memBlock pointer (in
>> >> include/csound_type_system.h), this would work for all of the arg
>> >> types.  (This would require a version bump.)
>> >>
>> >> With the type information made available, we should be able to do a
>> >> few interesting things. One, for any arg pointer, we could just
>> >> subtract sizeof(CS_TYPE*) to look up the type of the arg.  This means
>> >> we could get rid of things like xincod and xincod_str, which are sort
>> >> of hackish IMO.  We could also use this to do type checking for
>> >> pfields, which later opens up possibilities for sending more than just
>> >> strings and numbers in events.
>> >>
>> >> I'm going to continue looking into the runtime type stuff for the next
>> >> few days and will email any updates.
>> >>
>> >> Thanks!
>> >> steven
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> Open source business process management suite built on Java and Eclipse
>> >> Turn processes into business applications with Bonita BPM Community
>> >> Edition
>> >> Quickly connect people, data, and systems into organized workflows
>> >> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>> >> http://p.sf.net/sfu/Bonitasoft
>> >> _______________________________________________
>> >> Csound-devel mailing list
>> >> Csound-devel@lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Open source business process management suite built on Java and Eclipse
>> > Turn processes into business applications with Bonita BPM Community
>> > Edition
>> > Quickly connect people, data, and systems into organized workflows
>> > Winner of BOSSIE, CODIE, OW2 and Gartner awards
>> > http://p.sf.net/sfu/Bonitasoft
>> > _______________________________________________
>> > Csound-devel mailing list
>> > Csound-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Open source business process management suite built on Java and Eclipse
>> Turn processes into business applications with Bonita BPM Community
>> Edition
>> Quickly connect people, data, and systems into organized workflows
>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>> http://p.sf.net/sfu/Bonitasoft
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
h

This is really cool Steven. Am I right in saying that you need only
refer to the type on declaration of a variable? After which point you
no longer need the type identifier? As in:

myKrateVar:k init 0
printk 1, myKrateVar

Or must one do:

printk 1, myKrateVar:k

Either way, I like the departure from needing to start variables with
their type. Bravo.

On 4 July 2014 03:00, Steven Yi  wrote:
> I think the cost is pretty minimal for both performance and memory.
> For space, it adds the sizeof(CS_TYPE*) for all vars and constants.
> For time, it has to assign the type.  The additional work depends a
> bit on the number of variables that exist in an instrument or
> globally. I haven't done any proper benchmarks though.
>
> Just FYI, I have the type stuff working for global vars, local vars,
> string constants, and float constants. I need to do labels and pfields
> next, then check if this affects UDO args.
>
> To note, the following test code:
>
> gi_var = 22
> gk_var = 33
> gS_var = "TEST"
>
> instr 1
>
> prints "Testing constants...\n"
> print_type 44
> print_type "test"
>
> prints "Testing Global Vars...\n"
> print_type gi_var
> print_type gk_var
> print_type gS_var
>
> ivar = 300
> kvar = 400
> avar init 0
>
> prints "Testing Local Vars...\n"
> print_type ivar
> print_type kvar
> print_type avar
>
> turnoff
>
> endin
>
> currently prints:
>
> Testing constants...
> Variable Type: c
> Variable Type: S
> Testing Global Vars...
> Variable Type: i
> Variable Type: k
> Variable Type: S
> Testing Local Vars...
> Variable Type: i
> Variable Type: k
> Variable Type: a
>
> There is a bit of a discrepency here with the constants.  We don't
> have a const string type, just String, but we do have the c type,
> which is essentially a const double.  The setting of the type though
> can be easily changed though, so we can work that out later.  (Though,
> I'd argue that constants are sort of modifier of a type rather than a
> type in and of itself...)
>
> On Thu, Jul 3, 2014 at 7:44 PM, Andres Cabrera  wrote:
>> This is great, thanks. Do you think there would be a performance penalty? Or
>> would things be optimized by the compiler?
>>
>> Cheers,
>> Andrés
>>
>>
>> On Thu, Jul 3, 2014 at 9:09 AM, Steven Yi  wrote:
>>>
>>> Hi Joachim,
>>>
>>> Thanks!  Regarding explicit typing, I'd just mention that it's a
>>> necessary thing to enable user-defined types. Beyond that,
>>> implementing a formal type inference system would reduce the need to
>>> explicitly type a variable. So the steps should be:
>>>
>>> 1. enable explicit typing for existing types:
>>>
>>> myVar:a = vco2(440, 0.5)
>>>
>>> 2. implement user-defined types:
>>>
>>> data AmbiSig w:a,
>>>   x:a
>>>   y:a
>>>   z:a
>>> end
>>>
>>> myVar:AmbiSig = AmbiSig(0, 0.5, 0.3, 0.2)
>>>
>>> (the above is just an example I thought up, could be done differently)
>>>
>>> 3. implement formal type inference:
>>>
>>> ; may require some explicit typing for opcodes with polymorphic out
>>> types, but below assumes the type of myVar can be determined by later
>>> usage of the var
>>> myVar = vco2(440, 0.5)
>>>
>>> data AmbiSig w:a,
>>>   x:a
>>>   y:a
>>>   z:a
>>> end
>>>
>>> myVar2 = AmbiSig(0, 0.5, 0.3, 0.2)
>>>
>>>
>>> That basically covers the game plan I've got in mind.
>>>
>>> Also just as an update, I think that the change to CS_VARIABLE is not
>>> necessary and wouldn't work actually as memBlock is a pointer.  The
>>> change for that then is to store CS_VAR_MEM as the memBlock pointer
>>> instead of void*.  This would actually work just fine and I think
>>> would be a backwards compatible change.  I've started work on
>>> implementing the RTTI, and have so far implemented this for number
>>> constants.  I'm making my way through each arg type and will next
>>> report when things are implemented or if there is any serious blocks.
>>>
>>> Thanks!
>>> steven
>>>
>>>
>>> On Wed, Jul 2, 2014 at 2:51 PM, joachim heintz 
>>> wrote:
>>> > hi steven -
>>> >
>>> > these are exciting explorations. having explicit typing would make a lot
>>> > of code much more readable, and it would be good for beginners to know:
>>> > "i must declare the type of a variable at its first usage."
>>> >
>>> > so, hopefully parser3 is not too far.
>>> >
>>> > thanks and all best -
>>> >
>>> >         joachim
>>> >
>>> >
>>> > Am 01.07.2014 23:36, schrieb Steven Yi:
>>> >> Hi All,
>>> >>
>>> >> Just a status update: I'm slowly catching up after moving and did some
>>> >> exploratory work today for two things, explicit typing and runtime
>>> >> type identification. For explicit typing, which would be explicitly
>>> >> saying what type a variable is using something like:
>>> >>
>>> >> myAudioSig:a = vco2(440, 0.5)
>>> >> outs myAudioSig, myAudioSig
>>> >>
>>> >> I ran into a lexer/parser problem where myAudioSig:a gets parsed as a
>>> >> label then an unexpected "a".  I think for now I will table this item
>>> >> as this would be simpler to deal with using an updated lexer/parser
>>> >> ("Parser3").
>>> >>
>>> >> For RTTI, I think I have sorted out what needs to be done.  Currently
>>> >> there are the following arg types for opcodes:
>>> >>
>>> >> Pfield
>>> >> Local
>>> >> Global
>>> >> String Constant
>>> >> Float Constant
>>> >> Label
>>> >>
>>> >> To deal with each of these, I think the solution is to use this struct:
>>> >>
>>> >> typedef struct csvarmem {
>>> >>          CS_TYPE* varType;
>>> >>          MYFLT memBlock;
>>> >>      } CS_VAR_MEM;
>>> >>
>>> >> the struct would be used more for casting a block of memory rather
>>> >> than directly allocating.  For example, if we were going to store a
>>> >> STRINGDAT, we could have code like:
>>> >>
>>> >> CS_VAR_MEM* varMem = csound->Calloc(csound, sizeof(STRINGDAT) +
>>> >> sizeof(CS_TYPE*));
>>> >> varMem->varType = &CS_VAR_TYPE_S;
>>> >> ...do code that uses varMem->memBlock...
>>> >>
>>> >> and this kind of patter would replace only allocating
>>> >> sizeof(STRINGDAT) or whatever var type is there.
>>> >>
>>> >> I think using this, plus modifying CS_VARIABLE to move the CS_TYPE*
>>> >> varType member to just before the memBlock pointer (in
>>> >> include/csound_type_system.h), this would work for all of the arg
>>> >> types.  (This would require a version bump.)
>>> >>
>>> >> With the type information made available, we should be able to do a
>>> >> few interesting things. One, for any arg pointer, we could just
>>> >> subtract sizeof(CS_TYPE*) to look up the type of the arg.  This means
>>> >> we could get rid of things like xincod and xincod_str, which are sort
>>> >> of hackish IMO.  We could also use this to do type checking for
>>> >> pfields, which later opens up possibilities for sending more than just
>>> >> strings and numbers in events.
>>> >>
>>> >> I'm going to continue looking into the runtime type stuff for the next
>>> >> few days and will email any updates.
>>> >>
>>> >> Thanks!
>>> >> steven
>>> >>
>>> >>
>>> >> ------------------------------------------------------------------------------
>>> >> Open source business process management suite built on Java and Eclipse
>>> >> Turn processes into business applications with Bonita BPM Community
>>> >> Edition
>>> >> Quickly connect people, data, and systems into organized workflows
>>> >> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>>> >> http://p.sf.net/sfu/Bonitasoft
>>> >> _______________________________________________
>>> >> Csound-devel mailing list
>>> >> Csound-devel@lists.sourceforge.net
>>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> >>
>>> >
>>> >
>>> > ------------------------------------------------------------------------------
>>> > Open source business process management suite built on Java and Eclipse
>>> > Turn processes into business applications with Bonita BPM Community
>>> > Edition
>>> > Quickly connect people, data, and systems into organized workflows
>>> > Winner of BOSSIE, CODIE, OW2 and Gartner awards
>>> > http://p.sf.net/sfu/Bonitasoft
>>> > _______________________________________________
>>> > Csound-devel mailing list
>>> > Csound-devel@lists.sourceforge.net
>>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Open source business process management suite built on Java and Eclipse
>>> Turn processes into business applications with Bonita BPM Community
>>> Edition
>>> Quickly connect people, data, and systems into organized workflows
>>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>>> http://p.sf.net/sfu/Bonitasoft
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Open source business process management suite built on Java and Eclipse
>> Turn processes into business applications with Bonita BPM Community Edition
>> Quickly connect people, data, and systems into organized workflows
>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>> http://p.sf.net/sfu/Bonitasoft
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/

Hi Rory,

Yes, the plan is only on first time use that an explicit type is
required.  The work was already done during 6.0 such that the type of
an identifier is only determined once, then looked up from a table.
(In < 6.0, the type of an identifier was done every time by looking at
the first letter.) Because we have the table to store the identifier
and its type, we'd really only need the explicit type the first time
it is used.

My thought is that having code like this:

printk 1, myKrateVar:k

would actually be an error, as the type of the variable is already defined.

Another way to look at it is in C:

int myvar;
int myvar2 = 2;
myvar = 1;
doSomething(myvar, myvar2);

Note with myvar and myvar2, the first we declare its type, the second
we declare its type an initialize.  After the first two lines, we
never refer to the type, just the variable name.

I think this is pretty common across a lot of languages, so I'm
feeling reasonably confident that it would be a good way to go.  I'd
be happy to hear any other points of view though!

steven

On Fri, Jul 4, 2014 at 7:47 AM, Rory Walsh  wrote:
> This is really cool Steven. Am I right in saying that you need only
> refer to the type on declaration of a variable? After which point you
> no longer need the type identifier? As in:
>
> myKrateVar:k init 0
> printk 1, myKrateVar
>
> Or must one do:
>
> printk 1, myKrateVar:k
>
> Either way, I like the departure from needing to start variables with
> their type. Bravo.
>
> On 4 July 2014 03:00, Steven Yi  wrote:
>> I think the cost is pretty minimal for both performance and memory.
>> For space, it adds the sizeof(CS_TYPE*) for all vars and constants.
>> For time, it has to assign the type.  The additional work depends a
>> bit on the number of variables that exist in an instrument or
>> globally. I haven't done any proper benchmarks though.
>>
>> Just FYI, I have the type stuff working for global vars, local vars,
>> string constants, and float constants. I need to do labels and pfields
>> next, then check if this affects UDO args.
>>
>> To note, the following test code:
>>
>> gi_var = 22
>> gk_var = 33
>> gS_var = "TEST"
>>
>> instr 1
>>
>> prints "Testing constants...\n"
>> print_type 44
>> print_type "test"
>>
>> prints "Testing Global Vars...\n"
>> print_type gi_var
>> print_type gk_var
>> print_type gS_var
>>
>> ivar = 300
>> kvar = 400
>> avar init 0
>>
>> prints "Testing Local Vars...\n"
>> print_type ivar
>> print_type kvar
>> print_type avar
>>
>> turnoff
>>
>> endin
>>
>> currently prints:
>>
>> Testing constants...
>> Variable Type: c
>> Variable Type: S
>> Testing Global Vars...
>> Variable Type: i
>> Variable Type: k
>> Variable Type: S
>> Testing Local Vars...
>> Variable Type: i
>> Variable Type: k
>> Variable Type: a
>>
>> There is a bit of a discrepency here with the constants.  We don't
>> have a const string type, just String, but we do have the c type,
>> which is essentially a const double.  The setting of the type though
>> can be easily changed though, so we can work that out later.  (Though,
>> I'd argue that constants are sort of modifier of a type rather than a
>> type in and of itself...)
>>
>> On Thu, Jul 3, 2014 at 7:44 PM, Andres Cabrera  wrote:
>>> This is great, thanks. Do you think there would be a performance penalty? Or
>>> would things be optimized by the compiler?
>>>
>>> Cheers,
>>> Andrés
>>>
>>>
>>> On Thu, Jul 3, 2014 at 9:09 AM, Steven Yi  wrote:
>>>>
>>>> Hi Joachim,
>>>>
>>>> Thanks!  Regarding explicit typing, I'd just mention that it's a
>>>> necessary thing to enable user-defined types. Beyond that,
>>>> implementing a formal type inference system would reduce the need to
>>>> explicitly type a variable. So the steps should be:
>>>>
>>>> 1. enable explicit typing for existing types:
>>>>
>>>> myVar:a = vco2(440, 0.5)
>>>>
>>>> 2. implement user-defined types:
>>>>
>>>> data AmbiSig w:a,
>>>>   x:a
>>>>   y:a
>>>>   z:a
>>>> end
>>>>
>>>> myVar:AmbiSig = AmbiSig(0, 0.5, 0.3, 0.2)
>>>>
>>>> (the above is just an example I thought up, could be done differently)
>>>>
>>>> 3. implement formal type inference:
>>>>
>>>> ; may require some explicit typing for opcodes with polymorphic out
>>>> types, but below assumes the type of myVar can be determined by later
>>>> usage of the var
>>>> myVar = vco2(440, 0.5)
>>>>
>>>> data AmbiSig w:a,
>>>>   x:a
>>>>   y:a
>>>>   z:a
>>>> end
>>>>
>>>> myVar2 = AmbiSig(0, 0.5, 0.3, 0.2)
>>>>
>>>>
>>>> That basically covers the game plan I've got in mind.
>>>>
>>>> Also just as an update, I think that the change to CS_VARIABLE is not
>>>> necessary and wouldn't work actually as memBlock is a pointer.  The
>>>> change for that then is to store CS_VAR_MEM as the memBlock pointer
>>>> instead of void*.  This would actually work just fine and I think
>>>> would be a backwards compatible change.  I've started work on
>>>> implementing the RTTI, and have so far implemented this for number
>>>> constants.  I'm making my way through each arg type and will next
>>>> report when things are implemented or if there is any serious blocks.
>>>>
>>>> Thanks!
>>>> steven
>>>>
>>>>
>>>> On Wed, Jul 2, 2014 at 2:51 PM, joachim heintz 
>>>> wrote:
>>>> > hi steven -
>>>> >
>>>> > these are exciting explorations. having explicit typing would make a lot
>>>> > of code much more readable, and it would be good for beginners to know:
>>>> > "i must declare the type of a variable at its first usage."
>>>> >
>>>> > so, hopefully parser3 is not too far.
>>>> >
>>>> > thanks and all best -
>>>> >
>>>> >         joachim
>>>> >
>>>> >
>>>> > Am 01.07.2014 23:36, schrieb Steven Yi:
>>>> >> Hi All,
>>>> >>
>>>> >> Just a status update: I'm slowly catching up after moving and did some
>>>> >> exploratory work today for two things, explicit typing and runtime
>>>> >> type identification. For explicit typing, which would be explicitly
>>>> >> saying what type a variable is using something like:
>>>> >>
>>>> >> myAudioSig:a = vco2(440, 0.5)
>>>> >> outs myAudioSig, myAudioSig
>>>> >>
>>>> >> I ran into a lexer/parser problem where myAudioSig:a gets parsed as a
>>>> >> label then an unexpected "a".  I think for now I will table this item
>>>> >> as this would be simpler to deal with using an updated lexer/parser
>>>> >> ("Parser3").
>>>> >>
>>>> >> For RTTI, I think I have sorted out what needs to be done.  Currently
>>>> >> there are the following arg types for opcodes:
>>>> >>
>>>> >> Pfield
>>>> >> Local
>>>> >> Global
>>>> >> String Constant
>>>> >> Float Constant
>>>> >> Label
>>>> >>
>>>> >> To deal with each of these, I think the solution is to use this struct:
>>>> >>
>>>> >> typedef struct csvarmem {
>>>> >>          CS_TYPE* varType;
>>>> >>          MYFLT memBlock;
>>>> >>      } CS_VAR_MEM;
>>>> >>
>>>> >> the struct would be used more for casting a block of memory rather
>>>> >> than directly allocating.  For example, if we were going to store a
>>>> >> STRINGDAT, we could have code like:
>>>> >>
>>>> >> CS_VAR_MEM* varMem = csound->Calloc(csound, sizeof(STRINGDAT) +
>>>> >> sizeof(CS_TYPE*));
>>>> >> varMem->varType = &CS_VAR_TYPE_S;
>>>> >> ...do code that uses varMem->memBlock...
>>>> >>
>>>> >> and this kind of patter would replace only allocating
>>>> >> sizeof(STRINGDAT) or whatever var type is there.
>>>> >>
>>>> >> I think using this, plus modifying CS_VARIABLE to move the CS_TYPE*
>>>> >> varType member to just before the memBlock pointer (in
>>>> >> include/csound_type_system.h), this would work for all of the arg
>>>> >> types.  (This would require a version bump.)
>>>> >>
>>>> >> With the type information made available, we should be able to do a
>>>> >> few interesting things. One, for any arg pointer, we could just
>>>> >> subtract sizeof(CS_TYPE*) to look up the type of the arg.  This means
>>>> >> we could get rid of things like xincod and xincod_str, which are sort
>>>> >> of hackish IMO.  We could also use this to do type checking for
>>>> >> pfields, which later opens up possibilities for sending more than just
>>>> >> strings and numbers in events.
>>>> >>
>>>> >> I'm going to continue looking into the runtime type stuff for the next
>>>> >> few days and will email any updates.
>>>> >>
>>>> >> Thanks!
>>>> >> steven
>>>> >>
>>>> >>
>>>> >> ------------------------------------------------------------------------------
>>>> >> Open source business process management suite built on Java and Eclipse
>>>> >> Turn processes into business applications with Bonita BPM Community
>>>> >> Edition
>>>> >> Quickly connect people, data, and systems into organized workflows
>>>> >> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>>>> >> http://p.sf.net/sfu/Bonitasoft
>>>> >> _______________________________________________
>>>> >> Csound-devel mailing list
>>>> >> Csound-devel@lists.sourceforge.net
>>>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>> >>
>>>> >
>>>> >
>>>> > ------------------------------------------------------------------------------
>>>> > Open source business process management suite built on Java and Eclipse
>>>> > Turn processes into business applications with Bonita BPM Community
>>>> > Edition
>>>> > Quickly connect people, data, and systems into organized workflows
>>>> > Winner of BOSSIE, CODIE, OW2 and Gartner awards
>>>> > http://p.sf.net/sfu/Bonitasoft
>>>> > _______________________________________________
>>>> > Csound-devel mailing list
>>>> > Csound-devel@lists.sourceforge.net
>>>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Open source business process management suite built on Java and Eclipse
>>>> Turn processes into business applications with Bonita BPM Community
>>>> Edition
>>>> Quickly connect people, data, and systems into organized workflows
>>>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>>>> http://p.sf.net/sfu/Bonitasoft
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Open source business process management suite built on Java and Eclipse
>>> Turn processes into business applications with Bonita BPM Community Edition
>>> Quickly connect people, data, and systems into organized workflows
>>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>>> http://p.sf.net/sfu/Bonitasoft
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>> ------------------------------------------------------------------------------
>> Open source business process management suite built on Java and Eclipse
>> Turn processes into business applications with Bonita BPM Community Edition
>> Quickly connect people, data, and systems into organized workflows
>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>> http://p.sf.net/sfu/Bonitasoft
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listi

Sounds good to me!

hi steven -

one thought about this. you wrote:

"My thought is that having code like this:
printk 1, myKrateVar:k
would actually be an error, as the type of the variable is already defined."

i'd say that such a redundancy should rather be tolerated than lead to 
an error. my experience over the years is that young composers are not 
familiar with *any* programming language. something like max or pd is 
usually their first contact with it. and everything which makes csound 
more tolerant (without becoming incoherent) is a huge help for them (and 
for me to show csound as attractive choice).

python, in my opinion, is a good example for this way of being as 
tolerant as possible.

best -

	joachim


Am 04.07.2014 17:24, schrieb Steven Yi:
> Hi Rory,
>
> Yes, the plan is only on first time use that an explicit type is
> required.  The work was already done during 6.0 such that the type of
> an identifier is only determined once, then looked up from a table.
> (In < 6.0, the type of an identifier was done every time by looking at
> the first letter.) Because we have the table to store the identifier
> and its type, we'd really only need the explicit type the first time
> it is used.
>
> My thought is that having code like this:
>
> printk 1, myKrateVar:k
>
> would actually be an error, as the type of the variable is already defined.
>
> Another way to look at it is in C:
>
> int myvar;
> int myvar2 = 2;
> myvar = 1;
> doSomething(myvar, myvar2);
>
> Note with myvar and myvar2, the first we declare its type, the second
> we declare its type an initialize.  After the first two lines, we
> never refer to the type, just the variable name.
>
> I think this is pretty common across a lot of languages, so I'm
> feeling reasonably confident that it would be a good way to go.  I'd
> be happy to hear any other points of view though!
>
> steven
>
> On Fri, Jul 4, 2014 at 7:47 AM, Rory Walsh  wrote:
>> This is really cool Steven. Am I right in saying that you need only
>> refer to the type on declaration of a variable? After which point you
>> no longer need the type identifier? As in:
>>
>> myKrateVar:k init 0
>> printk 1, myKrateVar
>>
>> Or must one do:
>>
>> printk 1, myKrateVar:k
>>
>> Either way, I like the departure from needing to start variables with
>> their type. Bravo.
>>
>> On 4 July 2014 03:00, Steven Yi  wrote:
>>> I think the cost is pretty minimal for both performance and memory.
>>> For space, it adds the sizeof(CS_TYPE*) for all vars and constants.
>>> For time, it has to assign the type.  The additional work depends a
>>> bit on the number of variables that exist in an instrument or
>>> globally. I haven't done any proper benchmarks though.
>>>
>>> Just FYI, I have the type stuff working for global vars, local vars,
>>> string constants, and float constants. I need to do labels and pfields
>>> next, then check if this affects UDO args.
>>>
>>> To note, the following test code:
>>>
>>> gi_var = 22
>>> gk_var = 33
>>> gS_var = "TEST"
>>>
>>> instr 1
>>>
>>> prints "Testing constants...\n"
>>> print_type 44
>>> print_type "test"
>>>
>>> prints "Testing Global Vars...\n"
>>> print_type gi_var
>>> print_type gk_var
>>> print_type gS_var
>>>
>>> ivar = 300
>>> kvar = 400
>>> avar init 0
>>>
>>> prints "Testing Local Vars...\n"
>>> print_type ivar
>>> print_type kvar
>>> print_type avar
>>>
>>> turnoff
>>>
>>> endin
>>>
>>> currently prints:
>>>
>>> Testing constants...
>>> Variable Type: c
>>> Variable Type: S
>>> Testing Global Vars...
>>> Variable Type: i
>>> Variable Type: k
>>> Variable Type: S
>>> Testing Local Vars...
>>> Variable Type: i
>>> Variable Type: k
>>> Variable Type: a
>>>
>>> There is a bit of a discrepency here with the constants.  We don't
>>> have a const string type, just String, but we do have the c type,
>>> which is essentially a const double.  The setting of the type though
>>> can be easily changed though, so we can work that out later.  (Though,
>>> I'd argue that constants are sort of modifier of a type rather than a
>>> type in and of itself...)
>>>
>>> On Thu, Jul 3, 2014 at 7:44 PM, Andres Cabrera  wrote:
>>>> This is great, thanks. Do you think there would be a performance penalty? Or
>>>> would things be optimized by the compiler?
>>>>
>>>> Cheers,
>>>> Andrés
>>>>
>>>>
>>>> On Thu, Jul 3, 2014 at 9:09 AM, Steven Yi  wrote:
>>>>>
>>>>> Hi Joachim,
>>>>>
>>>>> Thanks!  Regarding explicit typing, I'd just mention that it's a
>>>>> necessary thing to enable user-defined types. Beyond that,
>>>>> implementing a formal type inference system would reduce the need to
>>>>> explicitly type a variable. So the steps should be:
>>>>>
>>>>> 1. enable explicit typing for existing types:
>>>>>
>>>>> myVar:a = vco2(440, 0.5)
>>>>>
>>>>> 2. implement user-defined types:
>>>>>
>>>>> data AmbiSig w:a,
>>>>>    x:a
>>>>>    y:a
>>>>>    z:a
>>>>> end
>>>>>
>>>>> myVar:AmbiSig = AmbiSig(0, 0.5, 0.3, 0.2)
>>>>>
>>>>> (the above is just an example I thought up, could be done differently)
>>>>>
>>>>> 3. implement formal type inference:
>>>>>
>>>>> ; may require some explicit typing for opcodes with polymorphic out
>>>>> types, but below assumes the type of myVar can be determined by later
>>>>> usage of the var
>>>>> myVar = vco2(440, 0.5)
>>>>>
>>>>> data AmbiSig w:a,
>>>>>    x:a
>>>>>    y:a
>>>>>    z:a
>>>>> end
>>>>>
>>>>> myVar2 = AmbiSig(0, 0.5, 0.3, 0.2)
>>>>>
>>>>>
>>>>> That basically covers the game plan I've got in mind.
>>>>>
>>>>> Also just as an update, I think that the change to CS_VARIABLE is not
>>>>> necessary and wouldn't work actually as memBlock is a pointer.  The
>>>>> change for that then is to store CS_VAR_MEM as the memBlock pointer
>>>>> instead of void*.  This would actually work just fine and I think
>>>>> would be a backwards compatible change.  I've started work on
>>>>> implementing the RTTI, and have so far implemented this for number
>>>>> constants.  I'm making my way through each arg type and will next
>>>>> report when things are implemented or if there is any serious blocks.
>>>>>
>>>>> Thanks!
>>>>> steven
>>>>>
>>>>>
>>>>> On Wed, Jul 2, 2014 at 2:51 PM, joachim heintz 
>>>>> wrote:
>>>>>> hi steven -
>>>>>>
>>>>>> these are exciting explorations. having explicit typing would make a lot
>>>>>> of code much more readable, and it would be good for beginners to know:
>>>>>> "i must declare the type of a variable at its first usage."
>>>>>>
>>>>>> so, hopefully parser3 is not too far.
>>>>>>
>>>>>> thanks and all best -
>>>>>>
>>>>>>          joachim
>>>>>>
>>>>>>
>>>>>> Am 01.07.2014 23:36, schrieb Steven Yi:
>>>>>>> Hi All,
>>>>>>>
>>>>>>> Just a status update: I'm slowly catching up after moving and did some
>>>>>>> exploratory work today for two things, explicit typing and runtime
>>>>>>> type identification. For explicit typing, which would be explicitly
>>>>>>> saying what type a variable is using something like:
>>>>>>>
>>>>>>> myAudioSig:a = vco2(440, 0.5)
>>>>>>> outs myAudioSig, myAudioSig
>>>>>>>
>>>>>>> I ran into a lexer/parser problem where myAudioSig:a gets parsed as a
>>>>>>> label then an unexpected "a".  I think for now I will table this item
>>>>>>> as this would be simpler to deal with using an updated lexer/parser
>>>>>>> ("Parser3").
>>>>>>>
>>>>>>> For RTTI, I think I have sorted out what needs to be done.  Currently
>>>>>>> there are the following arg types for opcodes:
>>>>>>>
>>>>>>> Pfield
>>>>>>> Local
>>>>>>> Global
>>>>>>> String Constant
>>>>>>> Float Constant
>>>>>>> Label
>>>>>>>
>>>>>>> To deal with each of these, I think the solution is to use this struct:
>>>>>>>
>>>>>>> typedef struct csvarmem {
>>>>>>>           CS_TYPE* varType;
>>>>>>>           MYFLT memBlock;
>>>>>>>       } CS_VAR_MEM;
>>>>>>>
>>>>>>> the struct would be used more for casting a block of memory rather
>>>>>>> than directly allocating.  For example, if we were going to store a
>>>>>>> STRINGDAT, we could have code like:
>>>>>>>
>>>>>>> CS_VAR_MEM* varMem = csound->Calloc(csound, sizeof(STRINGDAT) +
>>>>>>> sizeof(CS_TYPE*));
>>>>>>> varMem->varType = &CS_VAR_TYPE_S;
>>>>>>> ...do code that uses varMem->memBlock...
>>>>>>>
>>>>>>> and this kind of patter would replace only allocating
>>>>>>> sizeof(STRINGDAT) or whatever var type is there.
>>>>>>>
>>>>>>> I think using this, plus modifying CS_VARIABLE to move the CS_TYPE*
>>>>>>> varType member to just before the memBlock pointer (in
>>>>>>> include/csound_type_system.h), this would work for all of the arg
>>>>>>> types.  (This would require a version bump.)
>>>>>>>
>>>>>>> With the type information made available, we should be able to do a
>>>>>>> few interesting things. One, for any arg pointer, we could just
>>>>>>> subtract sizeof(CS_TYPE*) to look up the type of the arg.  This means
>>>>>>> we could get rid of things like xincod and xincod_str, which are sort
>>>>>>> of hackish IMO.  We could also use this to do type checking for
>>>>>>> pfields, which later opens up possibilities for sending more than just
>>>>>>> strings and numbers in events.
>>>>>>>
>>>>>>> I'm going to continue looking into the runtime type stuff for the next
>>>>>>> few days and will email any updates.
>>>>>>>
>>>>>>> Thanks!
>>>>>>> steven
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Open source business process management suite built on Java and Eclipse
>>>>>>> Turn processes into business applications with Bonita BPM Community
>>>>>>> Edition
>>>>>>> Quickly connect people, data, and systems into organized workflows
>>>>>>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>>>>>>> http://p.sf.net/sfu/Bonitasoft
>>>>>>> _______________________________________________
>>>>>>> Csound-devel mailing list
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Open source business process management suite built on Java and Eclipse
>>>>>> Turn processes into business applications with Bonita BPM Community
>>>>>> Edition
>>>>>> Quickly connect people, data, and systems into organized workflows
>>>>>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>>>>>> http://p.sf.net/sfu/Bonitasoft
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Open source business process management suite built on Java and Eclipse
>>>>> Turn processes into business applications with Bonita BPM Community
>>>>> Edition
>>>>> Quickly connect people, data, and systems into organized workflows
>>>>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>>>>> http://p.sf.net/sfu/Bonitasoft
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Open source business process management suite built on Java and Eclipse
>>>> Turn processes into business applications with Bonita BPM Community Edition
>>>> Quickly connect people, data, and systems into organized workflows
>>>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>>>> http://p.sf.net/sfu/Bonitasoft
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Open source business process management suite built on Java and Eclipse
>>> Turn processes into business applications with Bonita BPM Community Edition
>>> Quickly connect people, data, and systems into organized workflows
>>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>>> http://p.sf.net/sfu/Bonitasoft
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Open source business process management suite built on Java and Eclipse
>> Turn processes into business applications with Bonita BPM Community Edition
>> Quickly connect people, data, and systems into organized workflows
>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>> http://p.sf.net/sfu/Bonitasoft
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://