Hi Istvan,

I'm trying to figure out what this would look like in code, and it
seems to be--as you said--a bit hackish.  Would it look something
like:

istack stack 50

push ival1, istack
push ival2, istack
push ival3, istack
...
push ival4, istack

myUDO ival1, ival2, ival3, ..., istack

or

istack myUDO

ival1 pop istack
ival2 pop istack
ival3 pop istack
ival4 pop istack
ival5 pop istack
...

I guess it would save a little bit of typing versus using tableiw and
table with ftables and passing that back from a UDO, but then you
could at least use ftlen with the table to count the returned values
if you wanted to have a varying amount of items returned.  I guess a
stackCount opcode could enable that too with a stack.

But strictly in terms of programming techniques, this doesn't add any
new abilities than what can be done with ftables I think, so I'd say
it's not worth adding.  What might be nice would be some UDO's for
making working with ftables a bit easier, so that work with them like
a stack (i.e. a push opcode, a pop opcode).  I probably should have
done something like that for a FIFO queue with the code I posted
earlier today for the voice allocation test.

Those could be done as UDO's and might be useful as C opcodes too for
efficiency, but probably not necessary unless they really get used a
lot.

The one thing you did mention that isn't doable without wrapping with
calls to strset and strget is an ftable full of strings.  Or is that
possible?

steven



On 5/4/06, Istvan Varga <istvan_v@fibermail.hu> wrote:
> The stack opcodes for a, k, i, and S types should not be very hard
> to implement, so it may be possible to have them already in 5.02 if
> they are found to be useful.
>
> On Thursday 04 May 2006 15:48, David Akbari wrote:
>
> > I, for one certainly like the sound of this - it reminds me of the
> > things I like about using SC3. This would likely also work toward
> > unifying the Subinstr and UDO idea into a more coherent whole, under
> > the hood.
> >
> > Of course, a change of the magnitude suggested would hopefully coincide
> > with a release of version increment 5.03, as the 5.02 release date is
> > approaching rapidly and there are already a ton of new and exciting
> > frontends etc that should be out and available to the public to use
> > that arguably should take precedence over the exciting changes
> > suggested in the previous email.
> >
> > -David
> >
> > ps. new\n parser\n parser\n parser\n ;)
>
> Not sure if it would help much here, as the limitation is not on the
> syntax level.
> --
> Send bugs reports to this list.
> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
>