Am 11.12.2015 um 22:37 schrieb Le_Forgeron:

> If I was crazy, I would use C++ and a compiler as the parser, filling
> a scene object with other objects...

> Povray::Torus obj1(1,0.1);
> // texturing can be a post constructor operation
> Povray::Cone obj2( Povray::3DVector(0,0,0), 1, Povray::3DVector(), 2);

Still unnecessarily complex, as compared to (e.g.)

cone { <0,0,0>, <0,1,0>, 2 }


One of the key properties of a POV-Ray scene, which make the
requirements for the future SDL so unique, is that it may contain (A)
descriptions of complex algorithms as well as (B) descriptions of
hierarchical data, mixed arbitrarily.

XML, JSON & co. are useful for (B) but cumbersome for (A), while classic
programming languages excel at (A) but suck at (B).

(Add to this the fact that POV-Ray makes heavy use of vectors and
colours, which in most programming languages would have to be "bolted
on" artificially, which usually makes for less than ideal syntax.)


I re-iterate: The ideal SDL for POV-Ray has yet to be designed.

(POV-Ray 3.x SDL manages to cater to both requirements comparatively
well, but - as Dick correctly points out - sucks big time in terms of
consistency; also, it's somewhat outdated when it comes to describing
algorithms efficiently.)

I'm not writing this to crush people's hope for a new SDL; rather to the
contrary, I'd say. But I'd love to crush the hope of any language's
fanboys that their favorite language may become that new SDL, or even
form the basis of it, and -- maybe more importantly -- direct people
away from the (almost inevitably) fruitless search for an ideal existing
language, towards actually contributing to the task of defining a new
language from scratch (drawing some inspiration from other languages
where it seems fitting, but leaving well-trodden paths where they would
be inefficient).


One possible way of contributing to this process would be to simply
write down some hypothetical scene in whatever format you think a
next-generation POV-Ray SDL could look like. Some added text explaining
how that file format is structured would be nice to have, but could also
be deferred as a next step.


Remember, the format _must_:

- be efficient at describing static portions of a scene;

- be efficient at describing algorithms to construct portions of a scene
dynamically.

- be describing a scene in terms of essentially the same elements and
hierarchical structures as the current POV-Ray SDL (some individual
cleanup allowed, my favorite candidates there being the finish and
camera blocks);


As additional requirements, the format _must_:

- allow for two-step parsing, with the first step transforming the
verbose human-readable format into some kind of bytecode "program" that
is to be "executed" later by a virtual machine embedded into POV-Ray;
most notably this will prohibit "macros" from constructing only partial
statements, and dynamical generation of additional algorithmic portions
at execution time will probably be unavailable as well. (The idea behind
this requirement is to maximize parsing performance for scenes with
complex algorithms; the current plan calls for LLVM as the bytecode
format, allowing to even use just-in-time compilation of the scene file.)

- in its essential syntax be agnostic of the details of a scene's
elements and their hierarchy; e.g. the basic syntax must be unaware of
the fact that the element "texture" has a child element named "finish",
and instead only deal with the general fact that some elements have
child elements with specific names. (The idea behind this requirement is
manifold, from simplifying the parser to automatically enforcing more
consistency in the syntax, and even extending the exact same syntax to
user-defined elements.)


Also, the format _should_:

- support vectors and colours as native data types.

- provide some syntax to define custom geometric primitives, shading
models, and similar stuff.

Post a reply to this message