Am Mon, 13 Apr 2009 18:55:22 -0400 schrieb clipka:

> 
> I think however that the function-based approach is better, because it
> would define transformations as basically property-less. So nobody tries
> to do things like:
> 
>   sphere {
>     rotate { axis: <1,0,0>; angle: 30 deg; } as myRotate; translate {
>     vector: <1,2,3>; };
>   }
>   myRotate.angle = 60 deg;
> 
> Otherwise, POV-Ray would need to keep track of a stack of
> transformations applied to the object (and similarly all the texture
> patterns and such as well), just in case someone would want to modify
> one of the steps later.

Well, I think the point here is: Do we store references in variables or 
actual copies of the data? If we store references, then yes, POV-Ray 
would need to keep track of them in its internal state. If we don't then 
"myRotate.angle = 60 deg" would do nothing until we use myRotate in an 
object modification block. Thats the same problem as cloning vs. 
modifying objects in the scene.

> 
> This is definitely something we would want - but isn't lazy evaluation
> the domain of functions?
> 
> Maybe we could get a consensus by allowing for named parameters in
> functions.
> 

Yeah, I thought of blurring the distinction between functions and 
prototypes. Sometimes named parametres are useful, sometimes they are not 
needed. We could allow both, we just need a syntax for it.

Let's sum up the classic differences between a function and an object:
A function has the type of its return value as soon as parametres are 
bound to it. As long as no parameters are bound to it it has a type 
determined by the number (and type) of its arguments. An object always 
has the type it was given when it was created.
A function has parameters which are distinguished by their order. An 
object has members or properties with names.

If we add input properties which delay calculation of other properties to 
our language then functions and prototypes can perform the same task with 
a different syntax. I'm not to happy with that, _one_ way to do things 
should be enough.

> There should be, however, *some* distinction between the two in syntax
> (not only in defining them, but also in using them), so it is clear to
> the user that it makes no sense to try to manipulate the parameters of
> the function.
> 
>> I chose = instead
>> of : because of consistency
> 
>> and *= means composition of two
>> transformation and writing the result back to the lhs. Simply putting a
>> transformation inside a modification block does not work for me (it
>> works in POV 3 because it does not use object properties). There should
>> be something to signify that you are _applying_ this transformation.
> 
> In the language concept I have in mind, it would simply be (taking the
> freedom to make this a function again, albeit with named parameters):
> 
> sphere
> {
>   radius = 20;
>   center = <100, 0, 0>;
>   rotate_around_axis
>   (
>     axis = <.5, .5, .5>;
>     amount = 30;
>   );
> };
> 
> because, as already mentioned in the original post, expressions by
> themselves (whether they be from prototype-cloning or function-calling)
> are always *applied*. Note that a sphere would "know what to do" with a
> transformation being applied to it. Most importantly, it would know that
> it would have to update its children accordingly, too. Which a simple
> tampering with the spere's *own* transformation matrix wouldn't do.
> 
> (Granted, we'd probably want a way to allow for getter/setter methods
> anyway...)

Hm, now I'm getting a understanding of what you are aiming for. Then an 
operator meaning "apply" would also be nice, wouldn't it?

perhaps
MyTransformedSphere = MySphere ~ MyTransform;


> 
> Duh. I've just started laying out the basics of the language, and people
> already start exploiting its details :P
> 
Exploitation of details makes a programming language powerful ;) 
Unfortunately that means paying attention to details when designing a 
language is very important.

> Note however that this might be slower on a non-optimizing interpreter:
> It would have to copy the object first, then discard the original one.

It should be trivial to recognize a pattern like
<something> = <somthing>
{
  /*something*/
}

> It would also make a difference in case of:
> 
> MySphere = sphere {...};
> MySphereAlias = MySphere; // no prototype instantiation here, just an
> alias! modify MySphere {...};
> 
> (Then again, disallowing "modify" would prevent any misconception about
> how this case would work out.)
> 

Again, reference vs copy.

> 
> So how would you express such an "on-the-fly assignment" then?

I don't. If I want to I assign first and then reuse the assigned variable.

> The thing is, I don't like those interpunctuation prefixes: When you
> start lots of statements with these, it messes up the indentation,
> optically speaking.
> 

I'm not sure what you mean with "messing up the indentation", but people 
are used to such prefixes. Just think of directory structures:

. is the current working directory
.. is the parent directory
/ is the top level directory

and so on.

> 
> I'd prefer to avoid this "scene +=" - I think it's unnecessary bulk.
> Similarly with the "texture = texture" above.
> 
I see what you mean. So objects apply themselves to the global object 
which is the scene itself?

> 
> You mean the "for" loop? I find nothing wrong with it. The remainder of
> the syntax, that's what you came up with yourself :P
> 

I mean for ... end. I always find using words to open and close blocks 
hard to read.

> 
> Hm, yeah - you're making the point why I originally added the "modify"
> statement in the first place, but I forgot about it :}
> 
>> If we don't, we can't change objects that are already in the scene!
>> Note that the "modify" keyword is no solution to that problem.*/
> 
> Why isn't it? If the POV-Ray internals can cope with an object being
> modified, then this shouldn't be an issue.

Then "as" creates a reference, "modify" modifies the target of a 
reference, "=" creates a copy, and what does "modify" do if the variable 
it should modify is not a reference...

> 
> Yeah, basically. I'm quite sure about the underlying idea. I'm still
> struggling with the details, like how to get a syntax that is both
> perfectly consistent *and* looks good. Mostly the "center:..." vs.
> alternatives like "center=...", ".center=..." or some such doesn't yet
> satisfy me.
> 
> That, and your and Warp's objection against the "as" statement. I
> actually like it, but your complaint regarding inconsistency has some
> justification, too.

I just want to prevent SDL 4 becoming cluttered with keywords like "as" 
and "modify" when there is a way to express the same thing in a concise 
manner without them. This may seem pedantic but SDL 3 is such a mess with 
keywords. When I started writing #macros I just wanted to call a variable 
"x"... guess what happened ;)

Post a reply to this message