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

"MessyBlob" <nomail@nomail> wrote:
.... my point being that (with appropriate assignments) you can already know the
existing size of the sphere, given that the whole scene was constructued using
declarative statements.

Post a reply to this message

in news:web.49e39942d93ad1dd2dae03a10@news.povray.org clipka wrote:

> I'll try to describe what I have currently in mind. But first let me
> present to you a kind of "hello world" scene written in that
> language: 
> 
> 
> include "colors.inc";

include colors
 
> SphereCenter = <0,1,0>;

Spherecenter = <0,1,0>
Sphereradius = 1

> sphere {
>   center: SphereCenter;
>   radius: 1 as SphereRadius;
>   texture {
>     pigment { color: #<1,0,0> }
>   };
> } as MainSphere;

MainSphere = sphere {
  center = SphereCentre,
  radius = SphereRadius,
  texture {
    color = <1,0,0> 
    //(if we need more than a 3-vector define the kind rgbf<1,0,0,1>)
  }
}

... the as SphereRadius is confusing and obfusicating.

read http://docs.python.org/tutorial/controlflow.html#defining-
functions and espacialy the next section.

the alternative of the above Mainsphere thus should be:

MainSphere = sphere {
  SphereCentre,
  SphereRadius,
  texture {
    color = <1,0,0> 
    //(if we need more than a 3-vector define the kind rgbf<1,0,0,1>)
  }
}
... kind of exactly the same as we have now :)

taking it a bit further, the way to declare macros should be exactly as 
done in Python, but then in SDL:

macro Sphere(spherecentre=<0,0,0>,sphereradius=1, ...etc)

so using the Sphere macro in the scene looks exactly like using the 
built in sphere.

Now Warp will of course argue that this new Sphere thing should not be 
a macro but a class that inherits from the "objects" class so all the 
texture etc. stuff is readily available and he's right.

class Sphere(object){
  spherecentre=<0,0,0>
  sphereradius=1
  and all kinds of clever code to generate the object
}
 
 
> modify MainSphere {
>   radius: 0.9;
> };

MainSphere.radius=0.9

MainSphere{radius=0.9} could be mistaken for the declaration of a new 
sphere with radius, using the default centre and texture.

I realy like Python, but don't use it as an SDL but steal as much 
possible from it and use it in a sytax as close as possible tot the 
current SDL as possible and read:

The Zen of Python

    Beautiful is better than ugly.
    Explicit is better than implicit.
    Simple is better than complex.
    Complex is better than complicated.
    Flat is better than nested.
    Sparse is better than dense.
    Readability counts.
    Special cases aren't special enough to break the rules.
    Although practicality beats purity.
    Errors should never pass silently.
    Unless explicitly silenced.
    In the face of ambiguity, refuse the temptation to guess.
    There should be one-- and preferably only one --obvious way to do 
it.
    Although that way may not be obvious at first unless you're Dutch.
    Now is better than never.
    Although never is often better than *right* now.
    If the implementation is hard to explain, it's a bad idea.
    If the implementation is easy to explain, it may be a good idea.
    Namespaces are one honking great idea -- let's do more of those!


Ingo

Post a reply to this message

ingo wrote:

> I realy like Python, but don't use it as an SDL but steal as much
> possible from it and use it in a sytax as close as possible tot the
> current SDL as possible and read.

This may seem a little odd, but why not use Python as an SDL?  I've used the 
C/C++ API before, and it would give us a mature, byte-compilable language 
that could easily link to a render module.  I think the license is 
acceptable, and it's certainly more optimized than anything we could easily 
come up with.

We basically would end up using the C API to compile the actual ray-
intersection code, the actual 'raytracer'.  Callbacks can give Python the 
ability to shoot extra rays, and would potentially even allow the definition 
of objects' ray-intersection functions from SDL.

If not Python, then perhaps some other established language should be 
considered.

 - Peter Hokanson

Post a reply to this message