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

"MessyBlob" <nomail@nomail> wrote:
> Generally, we could go for partial OO implementation for the scene objects,
> which means that we don't carry per-instance methods, but instead just have the
> instances (with a single pointer) locate the methods for the class, along with
> the enumerated properties. The parser would be version-matched to the engine,
> which removes any opaque enumeration from the SDL source scripts.

I'd even go as far as to move the whole scene object handling into a separate
layer, with the SDL code only checking whether the object is *any* type of
scene object, and then deferring the handling to that "scene object wrapper"
layer.

That one could in turn be comprised of nothing more than a dynamic table with
objects and their respective actual types (with the core SDL implementation
handling only indices into that table; could be pointers though of course), and
a hard-coded lookup table for each type, mapping keywords to
pointers-to-members. Plus some wrap/unwrap code for some data types, if needs
be.

Thus, a statement like

    MySphere.translate(<2,3,4>)

would be resolved to (roughly):

    value = LookupName("MySphere");
    if (value->type == SCENE_OBJECT)
    {
      SceneObjectLayer->Invoke(value->handle, "translate", Vector3d(2,3,4));
    }

while SceneObjectLayer::Invoke(handle, name, param) would be implemented as
something like:

    obj = (SceneObject*)handle;
    objClass = obj->class();
    member = LookupMember(objClass, name);
    obj->member(Unwrap(param));

which would ultimately resolve to - in this case - a call to
Sphere::Translate(Vector3d v).

Post a reply to this message

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

Lukas Winter <web### [at] geloeschtremovethisandthedotbeforenet> wrote:
> Or even:
> MySphereProducingFunction = function(named pos)
> { sphere { midpoint = pos; /*...*/ } };
>
> Any object applied to a function block would be its return value.

Yes, that makes a lot of sense.

> 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 think functions should be just functions, and some rule would have to be
established how to handle missing or surplus parameters. Easiest would be to
discard surplus ones, and have missing ones set to "undefined".

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

I'd expect some specific prefix symbol reserved for them :P

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

Either way it messes with the imperative paradigm most mainstream languages
still follow today - if not on large scale, then at "molecular" level (e.g.
individual functions/methods/whathaveyou): "Do this; next do that; next do foo;
next do bar; ..."

Unless of course it's done in a totally transparent way. But then again I'd not
consider that a language trait, but some particular implementation's way of
optimizing things.


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

I'm not sure how that answers my question. I think we're getting a bit fuzzy
here.


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

Please not! Because, as you say yourself:

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

It would also raise a conceptual problem, becuase then

  MySphere = sphere { ... };

would not only be an assignment, but *also* an expression - which would evaluate
to a sphere instead. If we want "bare" expressions to be read as "attach this to
the current object", the logical consequence would be that this assignment would
*also* attach the sphere to the scene.

I don't think that is what we want.


So we do need different syntax for assigment statements and "on-the-fly
assignments".


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

I don't think you got my point.

My basic point was: Syntax should not only be concise and consistent, but also
pretty as well.

My example was the above, which was indeed a syntax I pondered a while to
distinguish members from variables, by simply prepending a dot before member
names, to allude to the "myInstance.myMember" notation common in mainstream OO
languages - making the empty name shorthand for "this", so to speak.

My argument was that in this particular syntax, the many leading dots on a line
would tend to visually "distort" the indentation, and that this would make the
code ugly.

So with an example for an ugly syntax, my conclusion was that I want the new
POV-SDL syntax to be pretty, and my appeal was to take beauty into
consideration besides conciseness, consistency and other traits.


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

How would you do that as a user in a language that - as an extreme example -
would go

  @ i [1,10] {
    ? i < 5 {
      <<i
    } | {
      <<"many"
    }
  }

instead of

  for i in 1 to 10 do
    if i < 5 then
      print i
    else
      print "many"
    end
  end

Fact is that every language carries its own inherent level of verbosity, which
you as a user typically cannot really influence much.


> 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

Agree; something like

  pov:sphere { ... }

wouldn't really go well.

But how about

  include "sphere" as pov;
  include "box";

in case you *do* want a namespace - which could give you

  pov.sphere { ... }

or straigtforward

  box { ... }

"al gusto".


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

Maybe. But I think everything is an improvement over the current "#while...#end"
anyway :P

Post a reply to this message

Am Thu, 16 Apr 2009 08:31:31 -0400 schrieb clipka:
> 
> I think functions should be just functions, and some rule would have to
> be established how to handle missing or surplus parameters. Easiest
> would be to discard surplus ones, and have missing ones set to
> "undefined".
> 
Please don't do that, hunting down bugs caused by uninitialized or 
undefined values can be tedious. In my opinion just signaling an error is 
better.
In my own perfect little language, functions with incomplete argument 
list would return functions that take the missing parameters. Return 
values would be written to properties of the function.

>> Right. Perl has named parameters but how they work seems rather obscure
>> to me. Just what you'd expect from Perl ;)
> 
> I'd expect some specific prefix symbol reserved for them :P
> 
No, in fact I think it's an extra hash as a parameter.

>> >> 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.
> 
> Either way it messes with the imperative paradigm most mainstream
> languages still follow today - if not on large scale, then at
> "molecular" level (e.g. individual functions/methods/whathaveyou): "Do
> this; next do that; next do foo; next do bar; ..."
> 
As long as you disallow side-effects like output or time dependent 
values, not at all. Then it's just "Do this; oh, you can't do that, you 
have to do that first; to do that, you have to do foo;  now you can do 
this; next do bar; ..." Of course if you do allow output as side effects 
then it would be all messed up.

> Unless of course it's done in a totally transparent way. But then again
> I'd not consider that a language trait, but some particular
> implementation's way of optimizing things.
> 
Actually, I'm tired of implementing lazy evaluation in strictly evaluated 
frameworks...
> 
>> > 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?
>> >

Sorry I didn't answer that. If I think about it, no, but I'm not sure... 

> [...]
> I'm not sure how that answers my question. I think we're getting a bit
> fuzzy here.
> 
> 
>> > 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:
> 
> Please not! Because, as you say yourself:
> 
>> Easy, because = returns the assigned variable. That does definitely
>> confuse a non-programmer who doesn't know the difference between = and
>> ==.
> 
> It would also raise a conceptual problem, becuase then
> 
>   MySphere = sphere { ... };
> 
> would not only be an assignment, but *also* an expression - which would
> evaluate to a sphere instead. If we want "bare" expressions to be read
> as "attach this to the current object", the logical consequence would be
> that this assignment would *also* attach the sphere to the scene.
> 
> I don't think that is what we want.
> 
Haven't thought about that, you're right. Then, perhaps we do want "as" 
after all. But it still seems to me like a duplicate of "=" where the lhs 
and rhs are swapped ;)

> 
> So we do need different syntax for assigment statements and "on-the-fly
> assignments".
> 


>> Every reference to a variable outside the current scope necessarily
>> does this, if I understand you correctly.
> 
> I don't think you got my point.
> 
> My basic point was: Syntax should not only be concise and consistent,
> but also pretty as well.
> 
> My example was the above, which was indeed a syntax I pondered a while
> to distinguish members from variables, by simply prepending a dot before
> member names, to allude to the "myInstance.myMember" notation common in
> mainstream OO languages - making the empty name shorthand for "this", so
> to speak.
> 
> My argument was that in this particular syntax, the many leading dots on
> a line would tend to visually "distort" the indentation, and that this
> would make the code ugly.
> 
> So with an example for an ugly syntax, my conclusion was that I want the
> new POV-SDL syntax to be pretty, and my appeal was to take beauty into
> consideration besides conciseness, consistency and other traits.
> 

I see the dots as reminders, that a variable resides in the current 
scope, and think it's good that they stand out a bit. Maybe we'll want 
properties and other variables to be clearly distinguished by such 
prefixes, then again I think the approach "everything is a property" is 
very elegant.
I still believe that if no prefix is specified, the variable/property to 
be accessed should be the most local one that's defined.

> 
>> > 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.
> 
> How would you do that as a user in a language that - as an extreme
> example - would go
> 
>   @ i [1,10] {
>     ? i < 5 {
>       <<i
>     } | {
>       <<"many"
>     }
>   }
> 

If this language allows me to define a construction that does the same as 
@ or ?, then it's fine. Maybe with

#for([int] list, #func(int)) = {@ i list { func(i) }}

for([1,10], #(i) {
  ? i < 5 {
     <<i
    } | {
      <<"many"
    }
  })

Then the langauge is powerful enough for me to create my own verbosity. I 
must admit that nobody would want to do things like that all the time, 
but then again this fictional language is an extreme example.

> 
>> 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
> [...]
> But how about
> 
>   include "sphere" as pov;
>   include "box";
> 
> in case you *do* want a namespace - which could give you
> 
>   pov.sphere { ... }
> 
> or straigtforward
> 
>   box { ... }
> 
> "al gusto".
> 
Just as long nobody forces me to use namespaces, that's fine by me.
> 
>> There should really be opinion polls among POV-Ray users to decide on
>> prettyness ;)
> 
> Maybe. But I think everything is an improvement over the current
> "#while...#end" anyway :P

right... no wait, that's a reserved word *g*

Post a reply to this message

Lukas Winter <web### [at] geloeschtremovethisandthedotbeforenet> wrote:
> then again I think the approach "everything is a property" is
> very elegant.
> I still believe that if no prefix is specified, the variable/property to
> be accessed should be the most local one that's defined.

Yes, I also think that would make for a clean thing, and in any other language
I'd quickly agree.

There is one thing here, however, that worries me:

In other languages, whenever a "more local" variable enters the scene, it is
clearly visible, because it is either declared, assigned to, or appears in a
formal parameter list.

In our language, a block like

MySphere = sphere {
  center = <1,2,3>;
  radius = 4.2;
};

would introduce "more local" variables only *implicitly*, by them being
properties of "sphere".

Now if in a later version of POV, "sphere" would ever happen to get an
additional property named "i" or "temp", it would break a whole lot of scripts,
like:

i = 0;
MySphere = sphere {
  center = x*i;
  radius = temp;
};

Granted, these variable names are an extreme example, and nobody in his sane
mind would probably introduce them as new object properties. But the same could
basically happen with *every* name.

> If this language allows me to define a construction that does the same as
> @ or ?, then it's fine. Maybe with
>
> #for([int] list, #func(int)) = {@ i list { func(i) }}
>
> for([1,10], #(i) {
>   ? i < 5 {
>      <<i
>     } | {
>       <<"many"
>     }
>   })
>
> Then the langauge is powerful enough for me to create my own verbosity. I
> must admit that nobody would want to do things like that all the time,
> but then again this fictional language is an extreme example.

I think you're quite an exception regarding this practice. Let alone that I
think it is bad style, because it makes the code hard to read for other users
of the language, who are accustomed to the standard syntax.

(In the trade I work in, for instance, such things as "rolling your own
language" would typically be a complete no-go.)

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> In our language, a block like
> [...]
> Now if in a later version of POV, "sphere" would ever happen to get an
> additional property named "i" or "temp", it would break a whole lot of scripts,
> like:
>
> i = 0;
> MySphere = sphere {
>   center = x*i;
>   radius = temp;
> };

You'd probably want new object properties to be write-only, so that names to the
right of assignments in the "sphere { }" block can then refer to the outer scope
(which makes the above code work as expected).

I'm not sure if any languages or parsers do this by default, but if your need is
great enough, then of course it could be programmed :o)

Post a reply to this message

"MessyBlob" <nomail@nomail> wrote:
> > i = 0;
> > MySphere = sphere {
> >   center = x*i;
> >   radius = temp;
> > };
>
> You'd probably want new object properties to be write-only, so that names to the
> right of assignments in the "sphere { }" block can then refer to the outer scope
> (which makes the above code work as expected).

Then what if I want to do

  modify MySphere {
    center = x*i;
    temp = temp*2;
  }

?

Aside from that, consistency would suffer from using different name resolution
rules for lvalues (i.e. the left side of an assignment) and rvalues (i.e. the
right side).

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> "MessyBlob" <nomail@nomail> wrote:
> Aside from that, consistency would suffer from using different name resolution
> rules for lvalues (i.e. the left side of an assignment) and rvalues (i.e. the
> right side).

Yes, that's the price, if you want to have the functionality :o)
It's a design decision, among many others we'll end up discussing.

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> Then what if I want to do
>
>   modify MySphere {
>     center = x*i;
>     temp = temp*2;
>   }
>
> ?

Given that it's all declarative, you'd define a local variable to hold the
value, doing something like this (assuming temp is a property of the sphere):

  myTemp = 1; // for example
  modify MySphere {
    center = x*i;
    temp = myTemp*2;
  }

Post a reply to this message