In article <39a01465@news.povray.org>, "Thorsten Froehlich" 
<tho### [at] trfde> wrote:

> Well, this is obviously not a feature of object oriented languages 
> only. 

I didn't say it was. But it would pretty much be necessary in order to 
add object-oriented capabilities. And once you add the features to make 
POV modular(binding of variables and macros to objects), it seems a 
small step to make it object-oriented(having copies of objects inherit 
the members).


> I agree that there hsould be some way to store data of 
> different types more easily, but I am not sure if C++/Java style 
> syntax would really be the most appropriate and easy to learn.

In my examples, I wasn't basing my syntax on C++/Java...the only 
similarity I can see is using the dot operator to access members, 
something that POV  already does.


> As said before, there are programming languages that fit the language 
> model of POV-Ray much better than C/C++/Java.

Your previous example didn't look very much like POV...and I am not 
talking about using the C/C++/Java model of objects.


> What is wrong with:
> 
> object
> {
>     PlainLensFlare
>     scale 5
>     translate < 5, 1, 6>
>     color < 1, 0, 0.5>
> }

How would you declare this? I used member macros to set variables in my 
example, because I don't see any easy way to set them automatically with 
this type of syntax. Would POV just look at each declaration, and look 
for a matching parameter for it? So if you have a float, a vector, and 
an object, POV would expect the first parameter to be a float, the 
second to be a vector, and the third to be an object?
Basically, how do you declare the syntax?
I couldn't come up with a good and simple solution, so I skipped that 
problem completely. :-)


> My major problem with it is that is obvious in all discussions about 
> an object oriented POV scene description language is that people who 
> are familiar with C/C++/Java seem be caught in the thinking that 
> every language should look this way. to quote the old Apple slogan 
> "Think Different"!
> In particular, I think the low level capabilities of C/C++/Java are 
> in the way of creating a simple and easy to learn object oriented 
> extension to the POV language.  As a matter of fact, due to the 
> completely different nature of C/C++/Java and POV, nobody having to 
> learn it would benefit from existing C/C++/Java documentation, books, 
> etc if he/she does not know any of them before.

I agree, which is why I am not basing my syntax ideas on C/C++/Java. 
Actually, I don't know of any language that does it this way, with 
objects being variables, only one "object" type, and objects inheriting 
from other objects, not from types. It seems a pretty simple and 
flexible idea, though, I would be very surprised if there isn't any 
language that does things this way.
And like I said before, the only real similarity I can see in the syntax 
is the dot operator, which is already used in POV and seems to be easy 
to understand.


> Well, I would say it would parse slower because certain access to 
> internal data structures of POV-Ray would surely take some time. 

If you were just doing a benchmark of parsing speed, it would be slower. 
But it could also allow doing things in ways that would be faster in the 
end, as well as being much easier to write and maintain.


> A more abstract language could hide these complex tasks behind the 
> POV scene language and use the many benefits of a hardwired access of 
> C++ (in POV-Ray 4.0) rather than doing it in small steps in the 
> interpreted POV scene language!

Are you suggesting a new POV language? Not a bad idea, in my opinion, 
but certainly not a popular one.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

In article <39a00a5c@news.povray.org>, "Thorsten Froehlich" 
<tho### [at] trfde> wrote:

> That a Smalltalk development system for the Mac does not have any 
> space in my budget for the next few years :-(

You mean the only Mac development system is expensive?
Note that I don't know anything about it, I have just heard it compared 
to Objective-C and Java.


> As for Objective-C, I have not programmed in it myself, but I have 
> gone over many of the (old) NextStep sample code a few years back.  
> It is not difficult to understand (compared to C++).

I'm planning on learning it for Cocoa, I have heard it's syntax is far 
cleaner than either C++ ir Java, but I am not sure I like the idea of 
doing *all* of the interface stuff in a graphical editor, no matter how 
good or simple to use it is supposed to be.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

On 20 Aug 2000 11:20:17 -0400, Warp wrote:
>
>  If #while-loops are indispensable, then so are #macros. Just think about
>recursive #macros. Although recursion is very similar to looping, it's
>easy to make a recursive #macro which functionality cannot be made with
>#while loops (because you would need a dynamic stack and there are no
>such things in povray (or at least not any efficient one)).

You can't do anything that requires a truly dynamic stack with a #macro,
either, as the max. recursion level is fixed.  Thus, anything you can do
with a #macro can be done with a #while loop and a few arrays.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:
: You can't do anything that requires a truly dynamic stack with a #macro,
: either, as the max. recursion level is fixed.

  Why? This is a bit silly. I don't see any reason to limit the recursion
level of macros. That's what dynamic memory allocation is for.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <39a0fd7f@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   Why? This is a bit silly. I don't see any reason to limit the recursion
> level of macros. That's what dynamic memory allocation is for.

Not on all systems the stack is at the other 4 GB (or even 2^64 Byte) end
of the address space. In fact, even on such a system, once stack and heap
together take more than the per address (register) size limit, they will
collide...

Besides, it would be _very_ dangerous for a good operating system to allow a
stack over a specific size.  Take this simple program* for example, it will
consume all your memory resources (even if you run out of process table
entries, assuming this does not result in a signal):

#include <sys/types.h>
#include <unistd.h>

void main(void)
{
    (void)fork();
    main();
}

Now, you either have a per application memory limit, but the stack will
still be able to grow and grow to this limit and then the program will crash
(i.e. the operating system will have to terminate it once the allowed
address space limit has been reached).

As you can see, there is a good reason to have a stack size limit in the
first place.  With only 128 process table entries and 2 GB per application
memory limit, this small program can consume 64 GB of memory (or swap
space)!   How would dynamic memory allocation help here? ;-)


    Thorsten


* Disclaimer: Don't run this program on a system you don't own. Some
administrators don't like such programs :-)

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <39a03553@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   I have never looked into the source code of any STL implementation, though.

You don't want to!  POV-Ray source code is better commented and organised
;-)    But it varies a bit from STL to STL...

>   References are pointers.
>   The syntax for references usually doesn't allow you to make so many things
> with them than with pointers, but basically they are the same thing.
>   So it doesn't matter if we call them references or pointers. The important
> thing is what do we allow and what we don't to do with them.

They do not have to be, at least in ISO C++.  Section 8.3.2 paragraph 3 of
ISO/IEC 14882:1998(E) states:

"It is unspecified whether or not a reference requires storage (3.7)."

Effectively this rule seems to exist to allow a compiler to optimise the
code much better.  And this rule also explains why there can't be references
to references, but of course there can be pointers to pointers!

>   In C++ pointers are very free (and thus dangerous) and references are very
> strict. For example, you can't assign a new value to a reference. In Java
> references are more free than in C++ because you can assign the references
> to point to new objects. This is an important feature because without it
> it wouldn't be possible to make lists and so on.

If I am not completely wrong, in other languages like Java the same rule
applies, and a reference could be something for more abstract than a simple
pointer, for example a index to a table of pointers.  This would allow very
effective memory management as memory could be compacted easily.

>   I have always said, that "it's not true at all that there are no pointers
> in Java, all the contrary: In Java _everything_ is a pointer".

Nope, it does not have to be.

> : Great argument!  Who cares if someone can read a POV scene and learn from
> : it, why should there be new novice users of POV-Ray?
>
>   So you say that we shouldn't give powerful tools to people who wants them
> only because newbies can't read the code?

Yes, if this excludes every person who is not a computer scientist or with a
strong background.  After all, POV-Ray is for artists creating interesting
images, but programmers creating complex programs that generate data for
another complex program (POV-Ray) that generates images.

I have to admit that I am not far from the argument for the need for a
modeller here...

>   No, I still think that it doesn't matter. Features are not left out because
> they are slow to parse.

That might be one of the problems of POV-Ray when talking about certain
_parser_ features  :-(

>   Yes, there's a cost in designing a OO-pov language. But that's not a cost
> for the user. The users will probably not notice much difference. Someone
> may sometimes post a weird OO-pov code in text.scene-files, but they are
> usually hard to read anyways ;)

People be able to understand how something works. Increasing the complexity
over a certain limit, it will scare people away instead of encouraging them
to try for themselves.   And why should we exclude the 99.9% of non-computer
scientists from being able to _understand_ even a single POV scene
description?


    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <chrishuff-65D487.15374920082000@news.povray.org> , Chris Huff 
<chr### [at] maccom>  wrote:

>> A more abstract language could hide these complex tasks behind the
>> POV scene language and use the many benefits of a hardwired access of
>> C++ (in POV-Ray 4.0) rather than doing it in small steps in the
>> interpreted POV scene language!
>
> Are you suggesting a new POV language? Not a bad idea, in my opinion,
> but certainly not a popular one.

To go back to the simplicity of parser features in earlier versions, i.e. no
macros and so on.  Even remove the declare statement.

Then, start from there and add the same features from scratch to be more
restrictive and combine it with a simple and powerful programming language
that can be fully integrated into the scene description much more
dynamically.  Details and features would have to be analysed very well in
advance, but then it might offer fantastic abilities.  Just image to be able
to create one object which can exist a million times just by a procedural
definition.  To keep this simple and easy to comprehend and fast to render,
a lot more would have to be done and researched, but I think something like
this is possible.


    Thorsten


PS: As for my other points, they where not specifically addressed to you,
but more general because I get the impression the discussions always start
because someone familiar with C/C++/Java starts thinking about "missing"
features...

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <chrishuff-1DB6BF.15421220082000@news.povray.org> , Chris Huff 
<chr### [at] maccom>  wrote:

>> That a Smalltalk development system for the Mac does not have any
>> space in my budget for the next few years :-(
>
> You mean the only Mac development system is expensive?
> Note that I don't know anything about it, I have just heard it compared
> to Objective-C and Java.

Last time I checked it was over $1200 with no student discount in sight :-(

> I'm planning on learning it for Cocoa, I have heard it's syntax is far
> cleaner than either C++ ir Java, but I am not sure I like the idea of
> doing *all* of the interface stuff in a graphical editor, no matter how
> good or simple to use it is supposed to be.

It depends, one can get used to it...


     Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:

> This still doesn't answer my question: Why?

One answer: More user friendly and less confusing through less #declaring, while
providing powerful tools for the more advanced POV user / include file author.

> Why would more OO features in the scene language improve its usability?

Mainly because it would remove the need to declare separate values and extra name
space. (And memory?)

Example:

camera{
   location <0,1,-5> + clock*<3,0,0>
   look_at 0 + clock*<5,0,0>
}

...compared to:

#declare cam_lookat = <0,1,-5> + clock*<3,0,0>;
#declare cam_move = 0 + clock*<5,0,0>;
camera{
   location cam_move
   look_at cam_lookat
}

In the first example, you can later just extract camera.location and camera.look_at
to get the values...no extra variables needed. Which code do you think looks cleaner
and more easy to use for a novice?


>
> Would it be easier to learn?

No difference, I'd say...because we're not talking about a complete change of
syntax, but an addition to the current language (think of it as extensions) that you
don't have to learn unless you want to use it (like when file I/O was added in v3.1
- it was a new function that could be used when needed - like a tool.)


> Would it be fast to parse?  Would it allow
> porting C/C++/Java programs to POV-script?

Parsing speed: no idea actually...but as Warp said: If it was parsing speed that
counted, macros would never have been introduced anyway.

Porting programs? Binary programs to an ascii POV scene file? Now it's my turn to
ask: "What?", "How?" and "Why?" :)

> In short : What are the _practical_ benefits for the scene description, the
> primary purpose of the POV scene description language?
>

In short: a more user friendly and powerful scripting language that removes the need
for separate declaration of certain values.

----------------------------------------------------
Mikael Carneholm, B.Sc.
Dep. of Computer Science and Business Administration


Personal homepage:
http://www.studenter.hb.se/~arch
E-mail:
sa9### [at] idautbhbse

Post a reply to this message

Thorsten Froehlich wrote:

> > : Great argument!  Who cares if someone can read a POV scene and learn from
> > : it, why should there be new novice users of POV-Ray?
> >
> >   So you say that we shouldn't give powerful tools to people who wants them
> > only because newbies can't read the code?
>
> Yes, if this excludes every person who is not a computer scientist or with a
> strong background.  After all, POV-Ray is for artists creating interesting
> images, but programmers creating complex programs that generate data for
> another complex program (POV-Ray) that generates images.
>

> People be able to understand how something works. Increasing the complexity
> over a certain limit, it will scare people away instead of encouraging them
> to try for themselves.   And why should we exclude the 99.9% of non-computer
> scientists from being able to _understand_ even a single POV scene
> description?

Sigh...I'm so tired of the fact that a lot of you believe that implementing OO in
POV should mean changing the language into something completely different...

Look, what POV could benefit from is OO extensions - not a totally new language
(why remove the good parts?)

In POV version 4.x (one of the first OO versions), a scene could either look like
this:

#include "colors.inc"

camera{
    location <0,1,-5>
    look_at 0
}

light_source{ <20,50-50> color White }

difference{
    sphere{ <0,0,0>, 1 }
    box{ 1,-1 scale 0.5 translate <0.5,0.5,-0.5> }
    pigment{ Red }
}


..or like this:

#include "my_imap_textures.inc"
#include "camera_macros.inc"
#include "linked_lists.inc"
#include "particle_physics.inc"
#include "incredibly_advanced_functions.inc"

#declare snake_part = sphere{ 0, 0.5 }
#declare snake_head = sphere like snake_part{ texture{ txSnakeHead }}
#declare snake_body = sphere like snake_part{ texture{ txSnakeBody }}

#declare TheSnake = ListMacro1(snake_head, snake_body, 20)
#declare snake_head_position = TheSnake.head.origin + TheSnake.head.translation;
MacroCam1(<0,1,-5>, snake_head_position)

#declare snake_path = spline{
    #include "myspline.spl"
}

TheSnake.follow(snake_path)

...depending on what you want to do and what level you're on.

WE SHOULD NOT REMOVE ANYTHING! JUST ADD A LITTLE FUNCTIONALITY!  (Sorry for
shouting...) :)

#declare CurrentPOVScript = subset of FutureOOPOVScript;

or maybe:

#declare FutureOOPOVScript = union{
    CurrentPOVScript
    AddedOOFunctionality
}

and NOT

#declare FutureOOPOVScript = difference{
    TotallyNewLanguage
    CurrentPOVScript
}

Well, you get the point....

;-)

----------------------------------------------------
Mikael Carneholm, B.Sc.
Dep. of Computer Science and Business Administration


Personal homepage:
http://www.studenter.hb.se/~arch
E-mail:
sa9### [at] idautbhbse

Post a reply to this message