Hi Michael,

I like the idea of having functions and opcodes be more
interchangable. It might as simple as upgrading functions to have
0xffff entries and then just looking for any opcode that can fit the
arg types given as long as it has one output arg (it's late here and
am about to go to sleep so can't think it through at the moment...)

Regarding tuples, the problems is that function calls and therefore
there would be another gray area as to what to do if well allow
function calls that return more than one arg, so this currently is
ambiguous:

ival = 1 + somefunc(ival2, ival3)

where somefunc returns two or more variables.  If the above returns
one var, the expanded opcode calls would look something like:

#i1 somefunc.ii ival2, ival3
ival = 1 + #i1

after being compiled, which is easy to make sense of.

steven

On 10/11/06, Michael Gogins <gogins@pipeline.com> wrote:
> There should be no difference between opcodes and functions -- that's my preference. Any opcode should be callable with (), and any function should be callable just with the function name. Csound already returns tuples for opcodes. This should be extended to functions.
>
> The mechanism doesn't need to be changed much, I think. Just give a base name to functions so they can be called as opcodes, or infer the base name to build the opcode list for the parser.
>
> If that turns out to be messy, then I would turn 180 degrees and mandate a strict separation between opcodes and functions. The present situation is too ambiguous for my taste.
>
> Regards,
> Mike
>
> -----Original Message-----
> >From: Steven Yi <stevenyi@gmail.com>
> >Sent: Oct 11, 2006 4:18 PM
> >To: Developer discussions <csound-devel@lists.sourceforge.net>
> >Subject: [Cs-dev] Functions, Polymorphic Opcodes
> >
> >Hi All,
> >
> >I've been looking into polymorphic opcodes as well as expression
> >function calls and have a few questions, some of which I think can
> >impact how we go forward. Some of this will be well known to some of
> >you, but I wanted to write it down for those who might not be familiar
> >as well as to help clarify it for myself. This email will be a bit
> >long, but the subject is a little complex and I think I need some
> >clarification.
> >
> >>From what I understand of the code thus far, function calls are
> >defined much like polymorphic opcodes except they do not have an
> >initial dsblksize 0xffff (or 0xfffe or other polymorphic indicators)
> >OENTRY.  The parser, when it encounters any opcode, checks to see if
> >the OENTRY found is an indicator that it is polymorphic by checking
> >the dsblksize is equal to one of the defined indicators (0xfffb
> >through 0xffff).  If so, depending on the type of polymorphic
> >indicator it does a check of argtypes for inputs or outputs and looks
> >up OENTRY's with the same name of the opcode but with extra types
> >appended to the end.  So a polymorphic opcode like "init" has this as
> >an initial entry:
> >
> >{ "init",   0xffff      /* base names for later prefixes,suffixes */    },
> >
> >and has these as the different OENTRY's to compare with:
> >
> >{ "init.i",  S(ASSIGN), 1,      "i",    "i",    init                    },
> >{ "init.k",  S(ASSIGN), 1,      "k",    "i",    init                    },
> >{ "init.a",  S(ASSIGN), 1,      "a",    "i",    ainit                   },
> >
> >and will use the information after the period to determine type (so,
> >with 0xffff, it says to look at the output argument, and if it's
> >i-type, use init.i, etc.).  Now, one can't directly choose init.i as
> >an opcode because periods are not allowed as part of the opcode name
> >when parsing.
> >
> >For functions, they are really just opcodes and when csound compiles
> >an ORC, it takes functions and compiles them down as opcodes (same as
> >expressions as a whole).  What I found in doing some iterating over
> >OENTRY's to try to figure out what makes a function a function is that
> >really, *any* opcode can technically be called as a function as long
> >as it has a single input an single output and is defined using the
> >polymorphic syntax (has a period in the name followed by a single char
> >for type).
> >
> >The old parser, in express.c, when it finds a text identifier, if
> >first does a check to see if is an opcode in the master OENTRY list
> >(only comparing the length of the text found(see sCmp) so "ampdb" will
> >match "ampdb.i"), if so, then appends an argument type to the end (the
> >type of the argument within the parentheses of the function) and let's
> >the otran do another lookup of the new opcode name with arg type
> >appended to find if that opcode exists.  If the identifier isn't found
> >to be an opcode name in the first place, it checks to see if it is a
> >variable type by looking at it's initial letters, then if not, finally
> >give a full out error.
> >
> >The only thing I found to identify an opcode as function is that all
> >of the functions are defined in a polymorphic way except they do not
> >have the initial polymorphic OENTRY(the 0xffff entry).  By not having
> >an initial polymorphic OENTRY, functions can not be used like opcodes
> >because the parser will not find a match for the opcode name. For
> >example, trying this:
> >
> >iamp ampdb p4
> >
> >will give you an error because ampdb isn't listed in the master OENTRY
> >list, only "ampdb.i", "ampdb.k", and "ampdb.a" are there.
> >
> >However, because there is no real function type and functions are just
> >opcodes, one *can* call an opcode that is not explicitly known to be a
> >function using function syntax if it happens to fit the polymorphic
> >naming convention.  So, an opcode like cpsmidib *can* be called like a
> >function:
> >
> >ival = cpsmidib(10)
> >
> >will *not* give an error.
> >
> >So the definition of a function in csound is really implicit rather
> >than explicit and is a matter of convention in defining OENTRY's.
> >
> >What I'd like to get some input on is where do we go from here, and
> >particularly, can we come up with an explicit definition of what is a
> >function?  Some thoughts I had were:
> >
> >1)Create a second table just for function opcodes, so that no standard
> >opcode can be called as a function.  When parsing expressions, the
> >lookup for identifiers would be in the function OENTRY table and not
> >the standard OENTRY table. This make a clearer distinction between
> >what is an opcode and what is a function and could allow further
> >language constructs to allow user-defined functions, i.e. something
> >like:
> >
> >function myFunc i, iii
> >  i1, i2, i3 xin
> >  ...code...
> >  xout ival
> >end
> >
> >While going this way makes things a bit clearer, it also continues to
> >hide the fact that functions are really just opcodes, and rate
> >information can be very confusing.  I'm not exactly in favor of this
> >but thought I'm not sure what way to go so I've put it here.
> >
> >2)Allow any opcode to be called as a function as long as meets a
> >certain criteria.  Doing this, we would have to create a very clear
> >specification on what allows an opcode to be called as a function,
> >including some sort of order of criteria of lookup, and would have to
> >be a little more involved than the current method.  If we allow a
> >broader definition of when an opcode can be called as a function, I
> >think it might be possible to allow user-defined opcodes to be called
> >as functions, though there is a complication there in that currently I
> >do not know if it is possible to define polymorphic user-defined
> >opcodes.  We can create something new for that though, doing something
> >like:
> >
> >opcode myOp 0xffff, 0 ; make UDO polymorphic
> >endop
> >
> >opcode myOp.i i,i
> >...
> >endop
> >
> >opcode myOp.k k,k
> >...
> >endop
> >
> >opcode myOp.a a,a
> >...
> >endop
> >
> >A definition I think might be appropriate would be an opcode with any
> >number of inargs but only a single outarg.
> >
> >
> >Even if we keep things exactly the way they are, I would really like
> >to get things clarified and documented as I haven't seen any
> >documentation on defining a function and so have gotten to this point
> >only by examining code.
> >
> >Any comments and feedbacks (and corrections!) greatly appreciated!
> >
> >Thanks,
> >steven
> >
> >-------------------------------------------------------------------------
> >Using Tomcat but need to do more? Need to support web services, security?
> >Get stuff done quickly with pre-integrated technology to make your job easier
> >Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> >_______________________________________________
> >Csound-devel mailing list
> >Csound-devel@lists.sourceforge.net
> >https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net