In article <38cc170a@news.povray.org>, "Johannes Hubert" 
<jht### [at] mailacom> wrote:

> Chris: Have you thought about adding CSDL directly into a patched
> version of POV-Ray?
> 
> Like some sort of preprocessor.
> ...
> The pached version would then first scan the script for "#begin_csdl ...
> #end_csdl" blocks (in all include-files too) and would "translate" them
> to real POV-script and replace the blocks with their corresponding
> POV-script code. The resulting script would then be handed to the
> standard POV-parser, who would never even see (or know about) the CSDL
> code.
> 
> Users that don't want to use the CSDL code don't have to. And usage of a
> plugin written in CSDL would be nothing more than an "#include"
> statement, where the whole "#begin_csdl" etc. would be in the include
> file.
> 
> One small problem: Parsing will be slower, since first the CSDL code
> needs to be parsed and translated, before finally POV-ray has to parse
> the result.
> However, a caching scheme to re-use the translation of previously parsed
> and unchanged CSDL blocks could certainly be implemented.

Hmm. The first problem: I am writing this in C++, POV is written in C. 
The second one: I don't know enough about the parser to attempt anything 
like this. It is a good idea for blending the two together, though. 
Maybe someone else can do it, or maybe I can do it when POV is rewritten 
in C++.
And of course, as you mentioned, parsing would be slower, even slower 
than ordinary POV code. One of the biggest advantages of a separate 
translator would be that the translator program could be significantly 
faster than the POV-Script parser, and could output code that would 
parse faster than it's human-written POV-Script equivalent(it could do 
this by unrolling loops, etc). A way to avoid re-translating by caching 
translated versions might be possible, but it is way beyond my 
capabilities.

I am working on a definition of a possible syntax, I will probably 
eventually post it in povray.off-topic to keep from wasting server 
space(because there will probably be several revisions).

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message