Hi Anthony,

Thanks for your reply (and very glad to see you back around)!

I have to say I don't know myself what's the best way to do the
preprocessor.  The old parser runs it inline; the new parser right now
is most separated into multiple passes, so adding a true preprocessor
pass would make sense to me.  We would probably have to add a stack of
some sort for mapping processed lines with original lines and original
file locations to do correct error reporting.  (BTW: The multiple
passes makes it very easy to separate out the code, but shouldn't be
too difficult to reinline everything into a single pass, if desired,
though that might makes things a little less managable in terms of
codebase maintenance).

I've been putting off the preprocessor stuff as well as error handling
and need to do more research myself on how to implement these things,
hoping that by the time I got to that, others perhaps with some
experience in this might get involved. =)

If the preprocessor stuff is inlined, then it'd be hard to do a pass
to do the outputting of processed code, but then again, I can't
imagine it being to difficult to do some code in python or just a
standalone tool that can do the same thing.

steven


On 10/16/06, Anthony Kozar <anthonykozar@sbcglobal.net> wrote:
> Thanks for your excellent work on this front, Steven!  I really wish that I
> could be more involved right now because these areas really interest me ...
>
> Regarding "preprocessor" statements, some people (including myself) have
> thought about how useful it would be to be able to expand #includes and
> macros without perfing and to save the expanded orchestra as a text file.
> Do you think that it will be possible to separate out this functionality
> with the new parser?
>
> Would it perhaps be better (at least "cleaner") to separate out all of the #
> stuff into a true preprocessor?  This would add an extra pass to orchestra
> parsing but might be beneficial if the score and orchestra preprocessors
> could be combined.  I believe that there are some lingering bugs in the
> score parser due to the interaction of the macro facility and the m and n
> statements.  (m and n use macro-like names, so I am not sure how feasible
> this is).
>
> Anthony
>
>
> Steven Yi wrote on 10/15/06 4:58 PM:
>
> > I just wanted to send an update on the parser.
>
> > Otherwise, after this, the big things left are if-then's, UDO's,
> > #includes, and macro's.  There are also the not so often used
> > expressions to implement (bitshifts and things like those) but I think
> > those won't be so bad as the functions to do expressions are already
> > setup and just need to add a case to a switch statement and handle it
> > there.
>
>
> -------------------------------------------------------------------------
> 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