Lukas Winter <web### [at] geloeschtremovethisandthedotbeforenet> wrote:
> Well, I think the point here is: Do we store references in variables or
> actual copies of the data?

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.

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

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);


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

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

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.


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


> 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 :))


> > 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 ;)

So are you saying that the concept I've presented is powerful? Thanks ;)

> Unfortunately that means paying attention to details when designing a
> language is very important.

Yup. Sure thing.

> > 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 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",

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.

Alas, it really "uglifies" the indentation!


> but people
> are used to such prefixes. Just think of directory structures:

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'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?

Yep. Well, *anything* that is a standalone expression theoretically does. But
only for some types of values the concept of "applying it to the scene" makes
sense.


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


> 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 {};

Note that this concept also allows creating an anonymous modified object "on the
fly", as in:

    (MyIntersect,MyNormal) = trace( MySphere { translate <2,3,4> } );


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

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.

Post a reply to this message