In article <48punuklg3k2jl8trmqh5r6r3eokpq9del@4ax.com>,
 ABX <abx### [at] abxartpl> wrote:

> > Huh? The internal functions have names, they are just defined through 
> > the functions.inc file instead of being built-in. 
> So what's the problem to define keywords for types this way ?

Slower parsing, for one. ;-)
Requiring an external include file. Potential conflicts with future 
keywords if you use all lower-case, not fitting in with the rest of the 
language if you use upper-case. Providing an include file and using 
integer codes would be much better than nothing though.


> > Patterns and other things that use noise would be able to use any 
> > function as the noise source.
> Interesting idea. Are you reserving rights to make patch for it ? ;-)

Heh, implementing it in the current POV would take a huge amount of 
work. I'm mainly thinking of it as something to be considered for the 
4.0 rewrite.


> If keyword make sense it can be always added as identifier during parsing.
> Otherwise it seems overloading for parser. I can't say I fully understand how
> parser works but I imagine with every new token it can slow down a little.
> Further I imagine patches for 3.5 will introduce a lot of new tokens so
> prasing can be overloaded. Tell me if it works differently.

I doubt adding a token slows things down significantly, for more complex 
scenes it probably takes a smaller and smaller fraction of the total 
time, and for POV 4.0, the scene will probably be compiled into 
bytecodes for a virtual machine to run...more tokens would slow down 
compiling slightly, but compiling will be a small fraction of the total 
time used before the scene renders.


> On the other hand I wonder if some propability of occurences could be
> introduced to parser. As source library from IRTC could be investigated for
> probability of keywords. Most probable keywords could be compared with parsed
> token first.

Or the parser could do something similar on the fly: if a token is 
matched, move it to the front of the list. Tokens that occur more often 
will spend more time towards the front of the list. Not as efficient, 
but simpler and adapts to the scene...for example, a mesh file will have 
a very different occurance distribution from other scenes, mainly having 
"triangle" or "smooth_triangle", "{}" braces, ",", "<", and ">" 
characters, and numbers. After the first triangle, these will be at the 
top of the token list. I did something similar for Sapphire: when a 
symbol is resolved it moves to the front of the symbol table.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message