Hi All,

I'm working on a new type checker at the moment to catch semantic
issues earlier in the parser than at compile-time (as was in CS5).
One thing I looked at last night were the current types listed for
OENTRY's.

One change to OENTRY argtype specification that I have already added
has to do with arrays. To keep with Csound's current system of of
first-letter denoting type, I modified the current type checking code
to allow multiple characters to define.  So for example, the array
opcodes uses:

    { "array_init", sizeof(ARRAYINIT), 0, 1, "[?;", "im", (SUBR)array_init },

    { "array_set", sizeof(ARRAY_SET), 0, 3, "", "[?;?M",
(SUBR)array_set, (SUBR)array_set },

    { "array_get", sizeof(ARRAY_GET), 0, 3, "?", "[?;M",
(SUBR)array_get, (SUBR)array_get },

where [ is found, the type system keeps parsing on up to a semicolon
to figure out the type of the array.  In this case, it's of ANY type,
denoted by "?".

This mechanism also allows potentially for non-single letter types.
For example, we could have something like:

":myType;aak"

where : would signify parsing the type from colon to semicolon.

Last night I was working on type checking and ran into the three other
cases of "types" we have.  Examples are:

union types:

                x       krate scalar or arate vector

 optional types:

                O       optional k-rate, defaulting to  0

 and var-args:

                y       begins indef list of aargs (any count)

Now, the last two really aren't types, but opcode calling features.
I'd like to propose:

1. Union Types - in the type system, allow unions so that the type
verifier can test against it.  For the above, x would be a k|a union.

2. Provide syntax for optional types:

akk=1;k=0;k=400;

The system would follow the mechanism for arg type specification done
for arrays.

3. Var-args aren't really a type as much as a calling convention for a
list of optional types.  Since there can only be only one var-arg type
at end, I was thinking:

akk...

where ellipsis at end would indicate var-args.

The reason for all of this is that the type verifier then could be
focused on types, and the other things which types were used could be
explicitly language features.


Also to note, this is a reworking of features already in Csound and,
IMO,  makes some things more explicit in terms of language design.
One thing that would be nice too is if we could unify also the way
opcodes specify args across the board, including User-Defined opcodes.

I think at a minimum, internally, I'm going to look at implementing
union types to simplify the type verifier. Because of the time frame,
I'll probably do the initial pass here regarding optional and var-arg
types using similar code what is currently existent from CS5.

Anyways, just wanted to get this info out and welcome any feedback.

Thanks!
steven

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net