Thorsten Froehlich <tho### [at] trfde> wrote:
: Hmm, what about a language more like an object oriented lisp. For example
: (OK, not a great one):

: set MyHouse to new house with 10 windows at <10,10,10>

: for every window of MyHouse add new curtain with colour red 0.4 green 0.9

  That's not even close to lisp.

-- 
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 <399f2983@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   That's not even close to lisp.

I did NOT say that this is close to Lisp...


   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:

> I am serious!  Why would an object oriented POV scene description language
> have to look like C++???   Surely not just because POV-Ray uses {} and
> dot-style vector attribute access?   Anybody remember DKBTrace - it used
> Pascal like syntax (and there was already a skyvase.dat)!
>

There's really nothing wrong with the current POV-Script syntax - all it needs
is some modifications to make it a (somewhat) fully object oriented language.
We should not change the language into something completely different, just
add some new features - like it was when file I/O was introduced in v3.1.

Just my 0,18 SKr.. (that's the value of $0.02, in swedish crowns!) :)

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

In article <399FE3F5.A96D722F@ida.utb.hb.se> , Mikael Carneholm 
<sa9### [at] idautbhbse>  wrote:

> There's really nothing wrong with the current POV-Script syntax - all it needs
> is some modifications to make it a (somewhat) fully object oriented language.

This still doesn't answer my question: Why?

Why would more OO features in the scene language improve its usability?
Would it be easier to learn?  Would it be fast to parse?  Would it allow
porting C/C++/Java programs to POV-script?

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


    Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
: I did NOT say that this is close to Lisp...

  Well, that's what your statement seems to imply:

: Hmm, what about a language more like an object oriented lisp. For example
       =====================      ====                    ====  ===========

: (OK, not a great one):

: set MyHouse to new house with 10 windows at <10,10,10>


  I undestand your statement that your example should look like lisp.

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

Thorsten Froehlich <tho### [at] trfde> wrote:
: This still doesn't answer my question: Why?

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

  What I am personally still missing from povray are dynamically allocated
objects (where, the objects in povray are indeed dynamically allocated, but
their syntax makes them quite static) and references or pointers to handle
them.
  That would allow making, for example, linked lists, trees and so on.

  If those were implemented in an object-oriented way, it would be a plus.
Making them in a C way would just cause a lot of spaghetti code.

  And object orientedness would help making better scripts. Perhaps most
users will not get any advantage of it, but most include file makers
certainly could.
  Just think about the possibilites. Include files using common abstract
base classes could be used more or less seamlessly together. Clear
interfaces will make them easy to use and maintain, and information hiding
will help avoiding all namespace trashing problems (there's nothing more
annoying than two include files using identifiers with same names).

: Would it be easier to learn?

  It doesn't matter. You don't have to learn it if you don't want it. The
fact that a feature is there doesn't mean you have to learn and use it.
You can let it be and leave the usage to the "experts" :)

: Would it be fast to parse?

  Would it be slower? Does it matter?

:  Would it allow
: porting C/C++/Java programs to POV-script?

  Why anyone would want to do this? They do different things.

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

  Ok, let's then remove identifiers and #while-loops and #macros. They have
no practical benefit, have they? You can do the same thing without them,
can't you?

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

Warp wrote:

>   Ok, let's then remove identifiers and #while-loops and #macros. They have
> no practical benefit, have they? You can do the same thing without them,
> can't you?

No you can't at least where #while loops are concerned. You would have
to use an external program to get the same funcionality. #macros could
be eliminated without loss of funcionality however.

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Ken <tyl### [at] pacbellnet> wrote:
: No you can't at least where #while loops are concerned. You would have
: to use an external program to get the same funcionality.

  Of course you can. Just write all the generated objects by hand.

: #macros could
: be eliminated without loss of funcionality however.

  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)).
  One example of recursive macros are tree generator macros.

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

Warp wrote:

>   One example of recursive macros are tree generator macros.

Thre were recursive tree include files around before macros were
introduced. PTDTree for example.

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

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

>   What I am personally still missing from povray are dynamically 
> allocated objects (where, the objects in povray are indeed 
> dynamically allocated, but their syntax makes them quite static) and 
> references or pointers to handle them.
> That would allow making, for example, linked lists, trees and so on.

Another built-in data structure might be sufficient for this. What I am 
talking about is a new data structure and functions for operating on it, 
a kind of tree which can link to any number of nodes. You could use it 
to build a linked list, a binary tree, an oct-tree, etc.
Maybe a separate "list" structure would still be useful, it would be 
more memory efficient than the above structure. Both of these would be 
easier to use and faster than their equivalents in POV-Script.

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