Am Tue, 14 Apr 2009 10:35:11 -0400 schrieb clipka:
> 
> I think we'll want to store references: Animation scripting might
> greatly benefit of that I guess. Instead of individually describing
> individual frames, an animation script could set up all its objects and
> then just push them around the scene as the animation progresses.
> 

Right. Then frames are just modification blocks of the scene object.

> 
> How about:
> 
> MyFunction = function(positional x, y; named a, b, c) { ... } //
> shorthand: function(x, y; named a, b, c) { ... }
> 
> Foo = MyFunction(2,3; b:42; a:11);
> 

Or even:
MySphereProducingFunction = function(named pos)
{ sphere { midpoint = pos; /*...*/ } };

Any object applied to a function block would be its return value.

> 
>> 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.
> 
> So far I can follow you... I think. Note however that with a dynamically
> typed language, even when parameters are bound to it, it has "the type
> of its return value" no earlier than it is actually executed and the
> actual return value determined.

Yes, from the syntactical point of view "func(/*...*/)" and "func" have 
different types in most languages. I don't like this, because what type 
has func(some_parameter /*but not the other*/) then? In most languages 
you have to specify all arguments or none... Seems to be a personal 
dislike, though ;)

> 
> I'd say that the parameter naming / ordering thing is rather independent
> of objects vs. functions: It's just a common convention of most
> programming languages that function parameters are passed by position
> instead of by name.
> 
Right. Perl has named parameters but how they work seems rather obscure 
to me. Just what you'd expect from Perl ;)

> 
>> 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.
> 
> I agree with that. But I guess the concept of individual properties
> delaying the calculation of a whole entity would be hard to grasp for
> the average user, or even for the average programmer (it is for me, at
> any rate ;)).
> 
It's just the other way round: The program doesn't follow a sequence of 
instructions but has a number of goals it has to achieve. Each time a 
resource needed to achieve the current goal is missing, the program goes 
to the next. Hopefully the resource will become available later, perhaps 
as the result of another calculation.

> 
>> 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;
> 
> Hm... there is something to this indeed.
> 
> However, some things need to be clarified:
> 
> Using bare expressions within a curly brace doesn't strictly create a
> copy, but modifies the copy of the prototype. Would the tilde operator
> force creation of a new copy?
> 
> In that case, it would be equivalent to:
> 
> MyTransformedSphere = MySphere { MyTransform };
> 
> which is just about as easy to type. It would also then raise the
> question whether the following would be possible, too:
> 
> MyColoredSphere = MySphere ~ color: #<1,0,0>;
> 
> In that sense, the tilde operator would actually be the single-statement
> equivalent for curly braces (which would happen to nicely fit with the
> shapes of the symbols :))
> 

Supplying your own rules for applying a object to some other object would 
just be an act of overloading the ~ operator. Something like

PaintInHappyColors = basic {}; //clone the most fundamental prototype

operator(object ~ PaintInHappyColors)
{
  pigment { color = <rand(), rand(), rand()>; };
}

> 
>> > 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.
> 
> 
> Hm... occasionally I do statements like:
> 
>     FooBar( This + Is(A * rand() - 0.4) / Stupid + Example );
> 
> only to find that I want to base something else on that very same random
> number - or some other sub-statement, for that matter. So sometimes I'd
> like to be able to write:
> 
>     FooBar( This + Is(A * rand() as MyRand - 0.4) / Stupid + Example );
>     Fnord = <1,2,3> * MyRand;
> 
> This is partially a thing of "how can that rand() dare to require me to
> give it a line of its own?!", partially "duh, now I have to cut and
> paste that sub-expression to its own line" laziness, and partially
> avoiding to type one instance of the variable name, as in:
> 
>     MyRand = rand();
>     FooBar( This + Is(A * MyRand - 0.4) / Stupid + Example ); Fnord =
>     <1,2,3> * MyRand;
> 
> Of course there are cases where using a full-fledged assignment
> statement is much cleaner. But sometimes, to me a value has the quality
> of no more than a "spin-off" of some other computation. So I'd love to
> have a statement saying "oh, by the way, just remember this one for
> later".
> 
> Or, think of debugging a large formula. With this "on-the-fly
> assignment", it is a piece of cake; no need stripping it down to
> individual terms (and risking to break it again as soon as you
> re-assemble it because you don't want 20 lines of assignments where a
> two-liner would do).
> 

The C way to do that:

while((error_code = function_returning_error_code()) == 0)
{
  /*do something*/
}

Easy, because = returns the assigned variable. That does definitely 
confuse a non-programmer who doesn't know the difference between = and ==.

So your example would become

FooBar( This + Is(A * (MyRand = rand()) - 0.4) / Stupid + Example );
Fnord = <1,2,3> * MyRand;

>> I'm not sure what you mean with "messing up the indentation",
> 
> Think of this syntax I had pondered:
> 
> sphere {
>   .center = <0,0,0>;
>   .radius = 1;
>   temp = rand();
>   texture {
>     test = temp + 1;
>     .answer = 42;
>   }
>   .foo = bar;
> }
> 
> I think this syntax would make it perfectly plain to most developers
> accustomed to the "foo.bar" field/member notation that .center is a
> property of the sphere, while for instance temp is not, and texture is
> defined in some other scope as well.
> 
Would it? I never write "this->member" in C++, just member. Some people 
prefix their members with "m_", I don't. It's a matter of personal 
taste...

> Alas, it really "uglifies" the indentation!
> 
Every reference to a variable outside the current scope necessarily does 
this, if I understand you correctly.

> 
> No problem with the prefixes, but I want the code to have a certain
> "beauty" as well - because with code, somehow beauty is almost always
> related to readability (unless of course you're going for the "exotic"
> beauty of some artificial languages like whitespace, c00l or such :P).
> 

> 
>> I mean for ... end. I always find using words to open and close blocks
>> hard to read.
> 
> That's where indentation was invented for. (There are even languages
> that actually use indentation levels to open and close blocks.)
> 
> And in a language such as this, I think there should be a clear
> distinction between the "modification blocks" - which open up a new
> context for "applying" things to - and control blocks.
> 
Another matter of taste, I suppose. It's just that when I want my code to 
be verbose, then _I_ want to introduce the verbosity, not the designer of 
the programming language I happen to code in.

> 
>> 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...
> 
> No - it's not "=" that creates a copy: This is just an alternative way
> of creating a reference.
> 
> The thing that causes creation of a copy is the curly-braces modifier
> block, unless explicitly used with "modify":
> 
>     MySphere = sphere;
> 
> actually creates a reference to the very basic "prototype of prototypes"
> sphere.
> 
> And why not? There's no reason to create a copy if you're not applying
> any modifications to it anyway.
> 
> To create a copy of that prototype, one would have to write:
> 
>     MySphere = sphere {};

Sounds good :)

> 
>> 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 ;)
> 
> Yeah, that's a hassle indeed.
> 
> One simple way out of this, however, is to develop a habit of always
> starting your variable names with uppercase letters. (I must confess I
> don't have such a habit myself ;))
> 
> Also note that the whole smash like "blob", "sphere", "triangle", "sqr"
> (yeah! my personal friend in POV 3.x!) would be made available at least
> for local variables if desired.
> 

As all objects will be prototypes I don't think any special treatment 
will be required. These prototypes could even come from special internal 
includes. Most of the time I won't need a poly and if I want to create 
one I just write

include "internal:poly"

poly
{ /*blahblah*/
};

Of course cameras and basic modifiers should be included by default. 
Namespaceing on the other hand is just too much typing for a lazy person 
like me :P

> If variable names should really be deemed an issue, how about carrying
> over POV-Ray 3.x convention for control keywords to start with "#"?
> 
> So we'd have:
> 
> #for i = 1 #to 21 #step 2 #do
> #end
> 
> though I wouldn't consider this pretty. Or using all uppercase, which
> seems to be more seldom used for variable names (possibly because it
> requires one more key to be pressed):
> 
> FOR i = 1 TO 21 STEP 2 DO
>   sphere { center = <i,0,0>; radius = 1; }
> END
> 
> Looks a bit antiquated, but that doesn't necessarily make it a bad idea.

There should really be opinion polls among POV-Ray users to decide on 
prettyness ;)

Post a reply to this message