In article <3e889ec9@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   * Assigment shortcut operators.
> 
>   That is, +=, -=, *= and /=.
>   The advantage is clear with statements like:
> 
> #declare Array[Index1*a*b+1][Index2] += 2;

Similarly, I'd like a #set directive, which modifies existing variables 
but can not make new ones. I made a patch for this, which is included in 
MegaPOV IIRC...it reduces typing, makes code clearer, and catches some 
errors sooner.

This loops infinitely:

#declare Loops = 10;
#while(Loops > 0)
    #declare loops = Loops - 1;
#end

And this produces an error:

#declare Loops = 10;
#while(Loops > 0)
    #set loops = Loops - 1;
#end

What I'd really like is for modification to be done without any keyword, 
as it is in most other languages...for example, the Sapphire equivalent:

def j: 10;
while(j > 0)
    j -= 1;


>   * #do - #until

Why do...until() instead of do...while()? Similar constructs, but 
do...while() seems more common.
Anyway, might as well add for loops of some sort while you are at it.


>   * Array operators for the string type.

And splines. Unify splines with the ones used by shapes like lathe and 
prism too.


>   * Float literals written as ascii chars (as in C).
> 
>   This way the above could be written as:
> 
> #declare MyString[a] = 'A';

Less useful, but no real argument against it.


>   * Binary file reading and writing.
> 
>   A read-command which reads (the specified amount of) raw binary data into
> a string identifier. In the same way it should be possible to directly
> write a string as raw data to a file (IIRC currently this is not possible
> because of a bug which causes the value 0 to not be written).
>   Also a seeking command would be good.

Agreed. I'm not really happy with POV's file handling. A more complete 
implementation would allow for importation of various model formats to 
be done from a POV script...DXF import could be done as a standard 
include file. It would go a long way toward reducing the need for 
plugins.


>   * Handling bitmaps with a 2-dimensional color array.
> 
>   A function should be added which reads the given image file into a given
> identifier, which is created as a 2-dimensional array of colors (exactly
> as if created by #declare Image = array[Width][Height];).
>   Also every item in POV-Ray which accepts an image should also accept
> such array of colors.
>   (Note: Functions for reading the image dimensions are not necessary
> because such function already exists: dimension_size().)

Hmm...not very memory efficient, and doesn't hook into POV's existing 
internal image handling. A separate data type might be better.


>   * Reading members of the global_settings and camera data with the
> dot operator.
>   * Some way of making dynamic data containers.

These could both be handled with the same mechanism...things like 
global_settings would be an object with things like max_trace_level as 
members.

I've posted messages about this before, but a prototype based object 
system would fit the POV language with few changes. "object" would 
become a basic, empty object (in the object oriented programming sense), 
and all the shapes would descend from it. Prototype OOP fits how complex 
shapes are already constructed, and is simpler than class based systems. 
As for references...perhaps a link directive of some sort.
Wedging all this into the POV syntax is kind of ugly though. It would be 
cleaner to just start over from scratch. This would allow a lot of crud 
to be stripped out of the language, and let interpretation be moved over 
to a virtual machine, for a great increase in speed for complex 
computations like tree generators or particle simulations. I propose a 
simple to use language for the main scene, and a more limited, very 
tightly optimized version for things like isosurfaces and shaders.

-- 
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