Hi All,

I'm looking at converting array arg specifiers for UDOs and Opcodes to use:

k[]

instead of:

[k]

Now, I took one stab at it this morning and got stuck and I remembered
what the current design is all about.  So internally, array vars are
specified in a way like this:

[k]   -> single dimension k-array
[[k]  -> two-dimension k-array
[[[a] -> three-dimension a-array
etc...

So the internal specifier for types is parsed and understood as:

1. If letter found, use as type
2. If '[' found, start searching as array argument.  For every '['
found in the beginning, add a dimension.  When '[' no longer found,
use everything from last '[' to first ']' found as type specifier for
the array, and search for ']' to close out that arg specifier.

Now, the issue is, this is the internal representation of array
arguments for opcodes.  This was fine as user's never saw it, only
opcode writers/editors working with OENTRY's.  This specification
later made it out to UDO's, and there was a call to change things such
that you could have something like:

opcode MyArrayProcessor a[], a[][]kk

This morning in trying to re-write things, I got stuck and got the
impression to move forward, the following should happen:

1. Keep the internal representation.  The code that searches on
first-letter being '[' is going to be simpler and more efficient than
doing a one-character look-ahead. Note too, the "[[k]" form is also
used as the names of array variables internally.

2. Redo the arg count and arg split functions to search for the
"a[][]" form instead of the of "[[a]" form.  However, for arg
splitting, at that point the arg specifier would then get re-written
to "[[a]" form.  All other code remains the same.


The impact would be, opcode writers, whether using C (OENTRY) or
Csound (UDO) code would use the "a[]" specification.  The current
internal array code would mostly stay the same.

I'm going to stash code I did just now and take a second attempt at
this following the above.  If anyone has some concerns please voice
them.

Thanks!
steven

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

One other note, I think there is a synthesizing of arg types as a
single string during compiling, made up of the in-args and out-args
from the csoundTree_t structs.  I need to verify, but if so, then I
think what would happen is that the current code would almost all stay
the same, and there would just be a single function called
csound_convert_to_internal_arg_string (or something like that) that
would get run before arg-splitting.

On Tue, Jun 25, 2013 at 1:36 PM, Steven Yi  wrote:
> Hi All,
>
> I'm looking at converting array arg specifiers for UDOs and Opcodes to use:
>
> k[]
>
> instead of:
>
> [k]
>
> Now, I took one stab at it this morning and got stuck and I remembered
> what the current design is all about.  So internally, array vars are
> specified in a way like this:
>
> [k]   -> single dimension k-array
> [[k]  -> two-dimension k-array
> [[[a] -> three-dimension a-array
> etc...
>
> So the internal specifier for types is parsed and understood as:
>
> 1. If letter found, use as type
> 2. If '[' found, start searching as array argument.  For every '['
> found in the beginning, add a dimension.  When '[' no longer found,
> use everything from last '[' to first ']' found as type specifier for
> the array, and search for ']' to close out that arg specifier.
>
> Now, the issue is, this is the internal representation of array
> arguments for opcodes.  This was fine as user's never saw it, only
> opcode writers/editors working with OENTRY's.  This specification
> later made it out to UDO's, and there was a call to change things such
> that you could have something like:
>
> opcode MyArrayProcessor a[], a[][]kk
>
> This morning in trying to re-write things, I got stuck and got the
> impression to move forward, the following should happen:
>
> 1. Keep the internal representation.  The code that searches on
> first-letter being '[' is going to be simpler and more efficient than
> doing a one-character look-ahead. Note too, the "[[k]" form is also
> used as the names of array variables internally.
>
> 2. Redo the arg count and arg split functions to search for the
> "a[][]" form instead of the of "[[a]" form.  However, for arg
> splitting, at that point the arg specifier would then get re-written
> to "[[a]" form.  All other code remains the same.
>
>
> The impact would be, opcode writers, whether using C (OENTRY) or
> Csound (UDO) code would use the "a[]" specification.  The current
> internal array code would mostly stay the same.
>
> I'm going to stash code I did just now and take a second attempt at
> this following the above.  If anyone has some concerns please voice
> them.
>
> Thanks!
> steven

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net