The POV-Ray 3.x SDL is, at its core, a language to describe static
hierarchical data structures in a quite efficient manner, with a
scripting language bolted on top later to also allow for dynamic
creation of data.

I think there's nothing fundamentally wrong with this approach;
specifically, I think the data description aspect of a POV-Ray scene is
so important that it is wiser to start with a data description language
and bolt a scripting language on top of it, rather than start with a
scripting language and extend it with data description elements (the
latter is the path of evolution that led to JSON). Therefore, in this
random proposal I will follow that same path.

As a starting point, I'll take an existing language that I consider
reasonably efficient at describing static hierarchical data structures:
JSON (defined in ECMA-404). For those who don't know it, this is what an
arbitrary JSON file looks like:

    {
      "firstName": "John",
      "lastName": "Smith",
      "isAlive": true,
      "age": 25,
      "address": {
        "streetAddress": "21 2nd Street",
        "city": "New York",
        "state": "NY",
        "postalCode": "10021-3100"
      },
      "phoneNumbers": [
        {
          "type": "home",
          "number": "212 555-1234"
        },
        {
          "type": "office",
          "number": "646 555-4567"
        }
      ],
      "children": [],
      "spouse": null
    }

A simple POV-Ray scene described in this format might look like this:

    {
      "camera": {
        "up": [ 0, 1, 0 ],
        "right": [ 1.33, 0, 0 ],
        "direction": [ 0, 0, -1 ],
        "location": [ 0, 0, 5 ],
        "look_at": [ 0, 0, 0 ]
      },
      "objects": [
        {
          "object_type": "light_source",
          "location": [ -100, 100, 100 ],
          "colour": "#FFFFFF"
        },
        {
          "object_type": "sphere",
          "location": [ 0, 0, 0 ],
          "radius": 1,
          "texture": {
            "pigment": {
              "colour": "#FFFFFF"
            }
          }
        }
      ]
    }

Notice how I chose to use the HTML-style colour format; this is a
comparatively random choice, probably because JSON lives in the same
ecosystem as HTML.

The first thing that strikes me is the fact that we have a vast number
of double quotes I, as a user, wouldn't want to have to type. As we'll
devising our own language anyway, we might therefore try to avoid them,
and I think we can accomplish this (even without breaking backward
compatibility to pure JSON) by addition of the following rule:

* If a string appears on the left-hand side of a name/value pair,
contains only uppercase letters, lowercase letters, digits and/or
underscores, does not start with a digit, and is neither "true" nor
"false" nor "null" (nor equivalent to any keyword we might add later),
the enclosing double quotes are optional.

Note that this mandates that we can't use character sequences of this
form for any other purpose.

We can also simplify our colour notation in a similar manner:

* If a string starts with "#", and the remainder of the string is
comprised solely of hexadecimal digits, the enclosing double quotes are
optional.

Also, the "object_type" thing bothers me; I therefore introduce /types/
to the language:

* An /object/ (in the JSON sense) may be preceded by a string specifying
its /type/.

This leaves us with the following scene description:

    {
      camera: {
         up: [ 0, 1, 0 ],
         right: [ 1.33, 0, 0 ],
         direction: [ 0, 0, -1 ],
         location: [ 0, 0, 5 ],
         look_at: [ 0, 0, 0 ]
      },
      objects: [
        light_source {
          location: [ -100, 100, 100 ],
          colour: #FFFFFF
        },
        sphere {
          location: [ 0, 0, 0 ],
          radius: 1,
          texture: {
            pigment: {
              colour: #FFFFFF
            }
          }
        }
      ]
    }

I think this constitutes a reasonable format for static scene
description; it's about as concise as the current format.

Now for bolting on a scripting language:

First we need control structure keywords; we don't want them to collide
with our unquoted strings, so I'll borrow a feature from POV-Ray 3.x
SDL: I'll prefix them with "#". For starters, I'll use the following:

    #if(CONDITION)
      ...
    #elif(CONDITION)
      ...
    #else
      ...
    #end

    #loop NAME
      ...
      #if(CONDITION) #break NAME #end
      ...
      #continue NAME
    #end

That'll be all we really need; we can bolt on more later (though we need
to make sure we don't get collisions with colour names).

Next we need variables; again we don't want them to collide with our
unquoted strings, so I'll use just about the same trick, except that I
use "@" to refer to variables.

As a matter of fact I'll define "@" as a prefix operator for string
expressions, meaning "the content of the variable with the name". I'll
use the following syntax to define variables for now:

    #global {
      "A variable name with blanks": 4711,
      Foo: [ 0, 1, 2 ],
      Bar: "Foo"
    }
    #local { ... }

I can now use the variables as follows:

    sphere: {
      radius: @"A variable name with blanks"
      center: @@Bar // look what I just did there
    }

I'll also extend the language by introducing non-literal values,
allowing mathematical operations and other some such, but I'll not go
into details there for now.

We could now modify our scene as follows:

    {
      camera: {
        up: [ 0, 1, 0 ],
        right: [ @image_width / @image_height, 0, 0 ],
        direction: [ 0, 0, -1 ],
        location: [ 0, 0, 5 ],
        look_at: [ 0, 0, 0 ]
      },
      objects: [
        light_source {
          location: [ -100, 100, 100 ],
          colour: #FFFFFF
        },
        #local { i: 1, n: 10 }
        #loop
          sphere {
            location: @i * [ 2, 0, 0 ],
            radius: 1,
            texture: {
              pigment: {
                colour: #FFFFFF
              }
            }
          }
          #local { i: @i + 1 }
          #if (@i <= @n)
            ,
            #continue
          #else
            #break
          #end
        #end
      ]
    }

There. Behold your new SDL, chilren of POV-Ray.


Or don't. Make alternative suggestions, or proceed from here.

One possible change to the syntax could be the use of regular braces
around list items instead of square brackets to specifically denote
vectors, if only to make it more pleasant to read. (As for using angular
brackets for this purpose, I never liked that part of POV-Ray 3.x's
syntax in the first place; also, in specific cases it has the potential
to collide with the greater-than sign.)

I'd also love to add ranges to the set of types, using a syntax akin to
this:

    [ 1 .. 20 ] // range from 1 to 20, both inclusive
    ( 1 .. 20 ) // range from 1 to 20, both exclusive
    [ 1 .. 20 ) // range from 1 inclusive to 20 exclusive
    ( 1 .. 20 ] // range from 1 exclusive to 20 inclusive

In general, I'd love the syntax to be geared more towards mathematical
notation, and I'd also like it to make use of Unicode mathematical
symbols as (entirely optional) syntactic sugar.


BTW, I don't consider the above syntax really good, most notably because
the possible location of control structures is poorly defined, which
makes the whole thing unsuited for a compiled language. It's really just
one random proposal thrown together in a matter of a few hours, in hopes
to kick off a more productive discussion about how the next generation
SDL might look like.

Post a reply to this message