Before I begin:

Just a question: should reused stuff be re-parsed and recompiled every time
we need it, as it is the case now with #include? Let's make the answer 'no'
for POV4. Then the new parser/compiler should rely on existing compilation
results to compile new stuff. Like Java does. But C/C++ does not.

This implies a repository for compiled stuff. That's a good thing, and
nobody in Java world complaints, on the contrary!

OK. I begin.

1) Let's say the top-level syntactic structures are classes and scenes.
   ---------------------------------------------------------------
Let's borrow from Java the structural organisation of classes and its
related notational features. We can write in
household/furniture/Stool.pov4:

package household.furniture;

import pov.primitive.*; // This import might be implicit and  not required
import pov.advanced.Isowood;

class Stool
{
    const DEFAULT_HEIGHT = 0.7;

    // let's define properties
    property height = DEFAULT_HEIGHT; // type not specified --> float.
Default value specified
    property leg_shape:object; // type specified ('object'). No default
value.
    property seat_shape = round_cylinder {...}; // Default value specified,
loose typing of variables

    // Default constructor (without parameters)
    make
    {
        // We make a 4-leg stool
        union
        {
            p = pigment{P_IW_06 color_map{CM_IW_02}}

            union
            {
                object {leg_shape translate <...>}
                object {leg_shape translate <...>}
                object {leg_shape translate <...>}
                object {leg_shape translate <...>}
                pigment {p}
            }
            object {seat_shape translate height*y}
        }

    }
}

This is better, I think, than having a #macro makeStool (...) <code> #end
somewhere in a #include'd file (with the old notation, is is difficult to
locate stuff we use).

2) Now, in our scene we want a stool. We write something like:
    ------------------------------------------------------
package scenes.indoor;

import <whatever is necessary>;

import household.furniture.Stool;

scene AmericanBar
{

    <stuff>

    Floor = plane {...}

    Stool // invokes the default constructor (without parameters)
    {
        // 'height' is not mandatory.
        // If not overridden, this property takes the default value

        // 'leg_shape' property is mandatory
        // Might be related to DEFAULT_HEIGHT, or Stool.DEFAULT_HEIGHT
        // if name is ambiguous (naming range)
        leg_shape box {...}

        dropon(Floor); // can be inherited from the 'object' top class

        translate <...>
    }

}

3) We want to create a magic stool
   -----------------------------
package household.furniture;

class MagicStool extends Stool
{
    // A magic stool glows
    property glowing_sphere:object.glow;

    // It has also levitation capabilities
    levitate (ceiling:object)
    {
        distance_to_ceiling = ceiling.y - max_entend().y; // max_extend is
an all-object property
        actual_height = min(height, distance_to_ceiling);
        translate actual_height*y
        rotate <grand(), grand(), grand()> // 'grand' is a global random
stream
     }
}


4) And in our scene
   ---------------

ceiling = plane {...}

MagicStool
{
    // we must specify the 'glowing_sphere' property.
    // Property names can be highlighted within a constructor by the editor.
    glowing_sphere glow{...}
    levitate (ceiling);
}

Quick comments on this embryo of pov4 syntax:
packages:
    Organise things, reuse already parsed and compiled code.

classes:
    Within packages.
    OO, but not too much. Only basic OO.
    Single inheritance
    constants, properties, methods, constructors

properties:
    Specific to the class being defined
    Used to create objects
    Different from variables (do not require '=' for valuation in
contructors blocks)

constructors:
    Invoke the 'make' method.
    The block specifies properties of the class. Syntax like
        ClassName
        {
            // for values that are instances of a class
            // i.e. value has a {...} block
            my_class_property <object value>

            // for primitive values (numbers, vectors, colors)
            my_primitive_property <value>;
        }
    Properties that have a default value are not mandatory in the
constructor block.
    If a non-defaulted property is not stated in the constructor block, the
parser generates an error.

It should be quite easy to generate Java classes from such a POV4 syntax.

Anybody interrested in digging in that direction? Or do you think it is a
dead-end?

Bruno

Post a reply to this message