I've done some pondering over Lua, wondering how it would be used to describe a
POV scene.

I think it doesn't work out. Neither does JavaScript, or many other languages
for that matter. Here's why:

POV-Ray is basically all about creating geometric objects in 3D space with
certain properties. The SDL should faciliate this.

Let's first look at the average mainstream language; Leaving aside syntax
details and focusing only on "grammar" instead, here's how this would be coded
in the average OO-enabled language:

- Create a new sphere named "fooSphere" at <x,y,z> with radius r.
- Create a new texture named "fooTexture".
- Create a new pigment named "fooPigment" with color <r,g,b>.
- Assign to "fooTexture" the pigment "fooPiment".
- Assign to "fooSphere" the texture "fooSphere".
- Translate "fooSphere" by <x,y,z>.
- Add to the scene the object "fooSphere".

Yuck. We all know this sucks.

So what *exactly* do we want? I think what we need is a grammar as close as
possible to this:

- With the scene...
-   Add to it a new sphere at <x,y,z> with radius r, and with that...
-     Assign to it a new texture, and with that...
-       Assign to it a new pigment with color <r,b,b>.
-   Translate it by <x,y,z>

Let's have a look at how this could be approximated with Lua:

We could pre-define special functions "scene", "sphere", "texture", "pigment"
and "translate", each taking the basic parameters, plus a variable list of
"modifiers", which in turn would be e.g. objects, textures, pigments or
transformations. This would giving us (for now ignoring the question of how
exactly to build vectors):

  scene (
    sphere ( <x,y,z>, r,
      texture ( pigment ( color <r,g,b> ) ),
      translate ( <x,y,z> )
    )
  );

Nice, isn't it?

Well, no. To see why, let's look at this one:

- With the scene...
-   Add to it a new blob, and with that...
-     Assign to it a new threshold t.
-     Add to it a new blob-sphere at <x,y,z> with radius r and strength s.

How would this translate in our Lua approach?

  scene (
    blob (
      threshold(t),
      blob.sphere ( <x,y,z>, r, s )
    )
  );

Obviously we forgot that "sphere" and "sphere" may mean two different things,
depending on context. (Granted, they're not very far apart; but it outlines the
underlying general problem.)

So what we did above was to exploit Lua syntax to come up with a shortcut for "a
new FOO, and with that... do BAR. do FUZZ.", when in fact what we *precisely*
want to express is "a new FOO, and with that... do FOO-BAR, do FOO-FUZZ".

I do not know any single scripting language providing syntactical sugar to
express exactly that in a concise manner - or at least providing a mechanism
that can be exploited to that end.

If anyone knows a comparatively well-established language providing exactly
that, please speak up. But I guess we really need to roll our own. (Though I
guess the core of Lua could still serve as a good basis, i.e. the virtual
machine and probably a good deal of the parser.)

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> I do not know any single scripting language providing syntactical sugar to
> express exactly that in a concise manner - or at least providing a mechanism
> that can be exploited to that end.

Anything that uses namespaces or class methods (or class qualifiers) would do
this. You might require that scripts use qualifiers though, unless you can make
the parser element automatically prioritise class scopes based on the innermost
container.

Post a reply to this message

"MessyBlob" <nomail@nomail> wrote:
> > I do not know any single scripting language providing syntactical sugar to
> > express exactly that in a concise manner - or at least providing a mechanism
> > that can be exploited to that end.
>
> Anything that uses namespaces or class methods (or class qualifiers) would do
> this. You might require that scripts use qualifiers though, unless you can make
> the parser element automatically prioritise class scopes based on the innermost
> container.

.... which is exactly my point: I think a next generation POV SDL should do this.
But I've never seen it in any language before.

Not in a small, concise language, that is. Note that POV's current SDL has it -
but at the cost of being context-sensitive about everything, without a clear
formal concept behind it: The language just happened to have grown that way.

Post a reply to this message

clipka wrote:
> I've done some pondering over Lua, wondering how it would be used to describe a
> POV scene.
> 
> I think it doesn't work out. Neither does JavaScript, or many other languages
> for that matter. Here's why:
> 
> POV-Ray is basically all about creating geometric objects in 3D space with
> certain properties. The SDL should faciliate this.
> 
> Let's first look at the average mainstream language; Leaving aside syntax
> details and focusing only on "grammar" instead, here's how this would be coded
> in the average OO-enabled language:
> 
> - Create a new sphere named "fooSphere" at <x,y,z> with radius r.
> - Create a new texture named "fooTexture".
> - Create a new pigment named "fooPigment" with color <r,g,b>.
> - Assign to "fooTexture" the pigment "fooPiment".
> - Assign to "fooSphere" the texture "fooSphere".
> - Translate "fooSphere" by <x,y,z>.
> - Add to the scene the object "fooSphere".
> 
> Yuck. We all know this sucks.
> 
> So what *exactly* do we want? I think what we need is a grammar as close as
> possible to this:
> 
> - With the scene...
> -   Add to it a new sphere at <x,y,z> with radius r, and with that...
> -     Assign to it a new texture, and with that...
> -       Assign to it a new pigment with color <r,b,b>.
> -   Translate it by <x,y,z>
> 
> Let's have a look at how this could be approximated with Lua:
> 
> We could pre-define special functions "scene", "sphere", "texture", "pigment"
> and "translate", each taking the basic parameters, plus a variable list of
> "modifiers", which in turn would be e.g. objects, textures, pigments or
> transformations. This would giving us (for now ignoring the question of how
> exactly to build vectors):
> 
>   scene (
>     sphere ( <x,y,z>, r,
>       texture ( pigment ( color <r,g,b> ) ),
>       translate ( <x,y,z> )
>     )
>   );
> 
> Nice, isn't it?
> 
> Well, no. To see why, let's look at this one:
> 
> - With the scene...
> -   Add to it a new blob, and with that...
> -     Assign to it a new threshold t.
> -     Add to it a new blob-sphere at <x,y,z> with radius r and strength s.
> 
> How would this translate in our Lua approach?
> 
>   scene (
>     blob (
>       threshold(t),
>       blob.sphere ( <x,y,z>, r, s )
>     )
>   );
> 
> Obviously we forgot that "sphere" and "sphere" may mean two different things,
> depending on context. (Granted, they're not very far apart; but it outlines the
> underlying general problem.)
> 
> So what we did above was to exploit Lua syntax to come up with a shortcut for "a
> new FOO, and with that... do BAR. do FUZZ.", when in fact what we *precisely*
> want to express is "a new FOO, and with that... do FOO-BAR, do FOO-FUZZ".
> 
> I do not know any single scripting language providing syntactical sugar to
> express exactly that in a concise manner - or at least providing a mechanism
> that can be exploited to that end.
> 
> If anyone knows a comparatively well-established language providing exactly
> that, please speak up. But I guess we really need to roll our own. (Though I
> guess the core of Lua could still serve as a good basis, i.e. the virtual
> machine and probably a good deal of the parser.)
> 
> 

I didn't quite understand your post. But, how about hash arrays?

scene =
{
	objects =
	{
		My_Sphere =
		{
			type = "sphere",
			location = <x,y,z>,
			radius = r,
			texture =
			{
				pigment =
				{
					color = <r,g,b>
				}
			},
			transformation =
			{
				translate = <x,y,z>
			}
		}
	}
};

This syntax is more akin to what you find in *markup languages*, but you 
can still easily modify the scene. Alternately, we could differentiate 
the content and behavior by using separate sections and languages for 
each (i.e. HTML and JavaScript in web pages).

However, I prefer using one language, since there's nothing a markup 
language like XML can do that a scripting language can't also do by 
using literal (i.e. terse or shorthand) syntax.

-Mike

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> "MessyBlob" <nomail@nomail> wrote:
> > Anything that uses namespaces or class methods (or class qualifiers)
> > would do this. You might require that scripts use qualifiers though,
> > unless you can make the parser element automatically prioritise class
> > scopes based on the innermost container.
> But I've never seen it in any language before.

I suppose we could introduce a parsing layer that understands the context of
keywords, and inserts the formal scope references, for presentation to a
standard language implementation. That would allow us to retain minimal SDL
code, and still use existing (open source) elements to help with interpreting
the transformed (fully-qualified) SDL.
(Sorry I have no experience with this, so can't give detailed examples)

Also, a question: How much change is acceptable from v3.x? If v3.x SDL code will
be broadly incompatible due to syntax changes, then I'm wondering if it would be
a mistake to hold onto the legacy SDL features that would make v4.x very
difficult to implement.
(That's an open question, rather than a hard opinion either way).

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> Yuck. We all know this sucks.

Doesn't JavaScript have the ability to assign properties to objects as they are
being instantiated?, e.g.

Sph = new Sphere( {
  radius: 1,
  position: [0,0,1]
} );

I'm not sure about assigning 'new objects as properties' within these
properties, e.g. creating a new material in the Sphere new object. Can anyone
clarify this?

Post a reply to this message

"MessyBlob" <nomail@nomail> wrote:
> I'm not sure about assigning 'new objects as properties' within these
> properties, e.g. creating a new material in the Sphere new object. Can anyone
> clarify this?

Just realised:

Sph = new Sphere( {
  radius: 1,
  position: [0,0,1],
  material: new Material( { ... } )
} );

And if you wanted to re-use an object, a simple reference would do:

myMaterial = new Material( { ... } );
Sph = new Sphere( {
  radius: 1,
  position: [0,0,1],
  material: myMaterial
} );

Post a reply to this message

> I didn't quite understand your post. But, how about hash arrays?
>
> scene =
> {
>  objects =
>  {
>   My_Sphere =
>   {
>    type = "sphere",
>    location = <x,y,z>,
>    radius = r,
>    texture =
>    {
>     pigment =
>     {
>      color = <r,g,b>
>     }
>    },
>    transformation =
>    {
>     translate = <x,y,z>
>    }
>   }
>  }
> };


Hmm... at first glance I thought it could do the desired thing - but it can't.
How, for instance, would the following translate?

sphere { <x,y,z>, r
    translate <a,b,c>
    pigment { ... }
    translate <d,e,f>
}

Filing both translate statements as "translate" in the hash map would overwrite
the first of them. Just combining the two would fail to properly affect the
pigment.


At the moment I'm pondering a syntax (of course not Lua nor JavaScript) that
would use the following:

    expression { statement1; statement1; ... }

as a shortand form for

    {
        temp = expression;
        ifdef(temp.statement1) temp.statement1; else statement1;
        ifdef(temp.statement2) temp.statement2; else statement2;
        ...
        return temp;
    }

(just a sketch here, but it might show where I want to go)

This would allow for the following:

    sphere(<x,y,z>,r) {
        translate (<a,b,c>);
        pigment { ... };
        translate (<a,b,c>);
    }

with sphere(center,radius) doing something like:
    sphere = function(center,radius) {

        temp = new object;
        temp.pov_object = pov_create_sphere(center, radius);
        temp.pigment = function() {
            temp = new object;
            temp.pov_object = pov_create_pigment();
            pov_attach_pigment_to_object(this.pov_object, temp);
            return temp;
        }
        temp.translate = function(v) {
            pov_translate_object(this.pov_object, v);
            pov_translate_object(this.pov_object.pigment, v)
        }
        return temp;
    }

In other words, there would be a "sphere" function creating a new POV-SDL
object, attach to it (a) a brand new POV-engine sphere, and (b) some methods
"translate" and "pigment" properties, thereby defining the semantics of these
when used in the context of the sphere.


> Alternately, we could differentiate
> the content and behavior by using separate sections and languages for
> each (i.e. HTML and JavaScript in web pages).

Yuck. We see that in the current SDL. It can be quite powerful, but it's not
really the way to go.

Post a reply to this message

"MessyBlob" <nomail@nomail> wrote:
> Also, a question: How much change is acceptable from v3.x? If v3.x SDL code will
> be broadly incompatible due to syntax changes, then I'm wondering if it would be
> a mistake to hold onto the legacy SDL features that would make v4.x very
> difficult to implement.

.... which would be?

I don't necessary want the new SDL to look like the old one. But I think the new
one should be just as concise. Which is problematic with general-purpose
languages.

Post a reply to this message

"MessyBlob" <nomail@nomail> wrote:
>
> Doesn't JavaScript have the ability to assign properties to objects as they are
> being instantiated?, e.g.
>
> Sph = new Sphere( {
>   radius: 1,
>   position: [0,0,1]
> } );

A host of languages has this.

The problem is still the scope: However you toss and turn it, you can't just go
ahead and do some stuff in the new object's scope (or "namespace" or however
you want to call it) without some added hassle.

The problem is that all mainstream languages do initialization of an object by
passing some expressions as parameters, with the expressions being evaluated in
the scope of the calling block. Plus they're evaluated before the object is
created, so can't have side effects on the object.

Post a reply to this message