I think user-defined functions would be great, and if you can do lexical scoping that would be even better. UDFs and lexical scoping would be 90% of a real programming language (user-defined structures would be the rest...).

Regards,
Mike

-----Original Message-----
>From: Steven Yi 
>Sent: Sep 5, 2006 3:44 PM
>To: Developer discussions 
>Subject: [Cs-dev] Parser Update
>
>Hi All,
>
>I wanted to send an email to update everyone on the parser work I've
>been doing.  I had gotten quite slowed down working to figure out how
>all the pointers are set up for the opcodes and instruments and after
>a bit of a circuitous route I've arrived back to reuse a number of the
>functions in otran.c for setting all of that up.  I do feel now that
>I've gotten a much better grasp and would like to at sometime redo
>that part of code to be more encapsulated, but for now I feel I've
>gotten to know it enough to know it'll do just fine as it is and to
>move on.
>
>I feel that now things are getting very interesting.  I have built a
>test suite and a testing tool in python (in the NewParser branch this
>is all in the tests folder).  The test tool so far is only moderately
>useful as parsing and semantic errors are not yet being truly reported
>to Csound so return values from running csound often come up 0 when
>they should be otherwise.  The test tool though does currently:
>
>-run all tests defined to run
>-prints test name and return value
>-captures output of all tests and saves in results.txt
>-has optional commandline to view the results of a run in a UI using
>Tkinter (python's version of Tk, which I chose because Tk is standard
>and comes with all versions of python)
>
>I have been adding tests one at a time and introducing a single
>feature each time to keep the process of development test-driven and
>incremental.
>
>I am looking at parsing and compiling expressions next.  This should
>take some time as I have not yet looked through express.c and the old
>parser to see what is involved.  Beyond the expressions I am planning
>to have functions implement single arguments first to match the old
>behavior, but want to make sure that functions will be able to handle
>multiple arguments in the future.  (Perhaps too sometime we should
>make User-Defined Functions a possibility, or make opcodes with single
>return values callable as functions?).
>
>My list of next actions after that are as follow:
>
>-redo bison parser file for instrument 0 to be generic (right now it
>has hardcoded values for what kinds of expressions it accepts, when it
>needs to match the behavior of the old parser and accept any
>statements that have allowable thread)
>
>-handle polymorphic opcodes: I have found the code that does the
>polymorphic check and resolution but need to fit it within the new
>parser at the right parser stage (should not be too difficult)
>
>-implement gotos and labels
>
>-handle if's, elseif's, and else's
>
>-implement UDO parsing (should be able to reuse instrument parsing
>code pretty easily to do this)
>
>-implement macros
>
>
>I think though that the most difficult parts seem to be past now and
>most of the work ahead looks not all too bad.  Doing the test suite
>and working by adding one feature for each test has made the work a
>lot more focused and easier to move ahead.  There's still a good bit
>of work left to do, but I think it's coming along quite well now.
>
>BTW: I am reusing quite a bit of code from the old parser but have
>been trying to break things down into smaller functions with
>descriptive names and using doxygen style comments.  I am aiming to
>make the new parser as easy to understand as I can make it so that
>others are more easily able to get up to speed with how Csound works
>and get involved with development.
>
>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

>>>>> "Michael" == Michael Gogins  writes:

 Michael> I think user-defined functions would be great, and if you can do lexical scoping that would be even better. UDFs and lexical scoping would be 90% of a real programming language (user-defined structures would be the rest...).

Just a line of disagreement; I like dynamic scope.  Indeed its loss is
largely why I stopped writing LISP.

==John ffitch

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net