"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

"clipka" <nomail@nomail> wrote:
> "MessyBlob" <nomail@nomail> wrote:
> > Doesn't JavaScript have the ability to assign properties [...]
> >
> > 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.

The class defines default property values in its constructor. Then when you
create instances, you can optionally assign values to the properties. So the
examples of 'radius' and 'position' are the names of the properties defined in
the class. I think this is a very elegant way of instantiating objects, with
syntax that is very similar to POV-Ray SDL.

Can you explain your thoughts on what the problem will be with this approach?
Are you thinking of transformations? Method-triggering property
assignments ('set' methods) achieve this, e.g. a "translate: [1,0,0]" property
would call ".doTranslate([1,0,0])" to change the transform matrix just like the
current SDL parser would. As I understand it, properties are set *after* object
instantiation, even if they are evaluated before the instantiation.

The JavaScript way seems better than the 'predefined parameters' approach of
most other languages, even when (with other languages) overloaded constructors
(variants that have different types or number of parameters) are specified in
the class.


One weakness I see with this approach, is when POV-Ray SDL containers may have a
number of children, e.g. with CSG, it might be better to use a ".add(new ...)"
method call to add child objects to the list.

(With apologies if I'm going over unnecessary background information; I don't
know how much you, or a typical reader, knows about JavaScript or OO).

Post a reply to this message

clipka wrote:
> 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.

True, but in this case maybe it's better to force the user to substitute 
a better solution? I.e.:

	scene.objects.MySphere.translation += <d,e,f>


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

While having XML *and* a scripting language might be yucky, I think that 
using separate conventions for content and behavior is a *good idea*. 
And, hash arrays are good in this regard.

I don't think using functions (i.e. keywords followed by parentheses) 
for everything is the way to go.

-Mike

Post a reply to this message