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

In article <399ff1e0@news.povray.org> , Warp <war### [at] tagpovrayorg>  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
>        =====================      ====                    ====  ===========
[...]
>  I undestand your statement that your example should look like lisp.

Well, English and German are belong to the same family of languages, yet
they do not look the same either.  Yet the "idea" (history), if there is
such a thing behind a spoken language, is the same.

So, please do not read my "like" as "looks like", but if the plain "like" is
not precise enough for you as "inspired by" Lisp.  Also, you cannot just
pick a few words of a sentence and ignore the rest:  I didn't say "like
Lisp", I said "like an object oriented lisp" - note the words _between_
"like" and "Lisp" :-)

As for the actual "idea" behind Lisp is the abstraction _and_ the way it is
implemented, this is the actual similarity between the examples I provided
and any example doing the same in Lisp.  I played it safe by using an
example which would in this style nearly work in a language I know:
AppleScript (which is very similar to HyperTalk).

And at least HyperTalk is considered to be part of the same language family
Lisp is a member of (also it is not _close_ to Lisp syntax)...


     Thorsten


PS: I tried to find a good link to some place proving my statement, but
unfortunately any search for Lisp and AppleScript or Hypertalk return tons
and tons of resume pages <sigh>   The closest but not very well discussed
note I could find is at <http://www.useit.com/papers/tripreports/ht89.html>.
I don't have any of my Prog. Language (History) books here in Germany, so I
can't give you any printed references right now :-(

____________________________________________________
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 <399feed3@news.povray.org>, "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?

I've often wished I could store a bunch of different types of data for a 
data structure in one chunk. Objects are an obvious place to put them. I 
had to settle for a bunch of global arrays, and eventually gave up.
The technique of #declaring a bunch of variables and #indluding a file 
is clumsy and can lead to variable name conflicts. Macros don't have 
variable numbers of parameters, so you sometimes have to resort to the 
same thing: #declaring variables before calling the macro. Long lists of 
macro parameters are difficult to keep track of. If object-oriented 
features were added, you could simply declare an object that does 
whatever was done by #including or calling a macro. For example, a lens 
flare object could be used like this:

#declare MyFlare = object {PlainLensFlare};

MyFlare.SetSize(5);
MyFlare.SetPos(< 5, 1, 6>);
MyFlare.SetColor(< 1, 0, 0.5>);
object {MyFlare.CalculateFlare();}

#declare MyFlare = object {SparkleLensFlare};
MyFlare.SetSize(2);
MyFlare.SetPos(<-5, 1, 6>);
MyFlare.SetColor(< 0, 1, 0>);
object {MyFlare.CalculateFlare();}

MyFlare.SetPos(< 0, 5, 6>);
MyFlare.SetColor(< 1, 1, 0>);
object {MyFlare.CalculateFlare();}

This would make 3 lens flares, a purple one to the right, a smaller 
green one to the left, and a yellow one above. You would only need to 
specify the parameters which you want to change, you could have as many 
as you want with no trouble, and you would have far fewer problems with 
variable name collision, since you would only need to watch out for the 
object names, not the parameters. If you wanted to make a slightly 
different lens flare, you wouldn't have to copy/paste a bunch of code 
from the original include and modify it, you could just make an object 
from one of the original objects and override some of the member macros.


> Would it be easier to learn? 

No, but since the existing language wouldn't need to be disturbed, you 
wouldn't have to learn it. It would be considerably easier to learn than 
C++, though.


> Would it be fast to parse? 

It probably wouldn't be noticeably slower without benchmarking, and 
could possibly allow doing some things in a way that would parse faster 
than previously possible.


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

No more than you can already port C or Pascal programs to POV-Script. 
Why would you want to do such a thing, anyway?


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

-- 
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 <chrishuff-47A4E5.19070718082000@news.povray.org> , Chris Huff 
<chr### [at] maccom>  wrote:

> What do you know about Smalltalk and Objective-C?

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

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


     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-5D4489.11363420082000@news.povray.org> , Chris Huff 
<chr### [at] maccom>  wrote:

> I've often wished I could store a bunch of different types of data for a
> data structure in one chunk.

Well, this is obviously not a feature of object oriented languages only.  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.

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

> #declare MyFlare = object {PlainLensFlare};
>
> MyFlare.SetSize(5);
> MyFlare.SetPos(< 5, 1, 6>);
> MyFlare.SetColor(< 1, 0, 0.5>);
> object {MyFlare.CalculateFlare();}

What is wrong with:

object
{
    PlainLensFlare
    scale 5
    translate < 5, 1, 6>
    color < 1, 0, 0.5>
}

I understand that there are cases when it appears to be the best way to use
the kind of syntax you suggest. (continues below)


>> Would it be easier to learn?
>
> No, but since the existing language wouldn't need to be disturbed, you
> wouldn't have to learn it. It would be considerably easier to learn than
> C++, though.

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.

To quote [1] Tog talking about the JavaScript in "How Programmers Stole the
Web":

>> And from whence arose this new syntax? It was derived from, and I am quoting
here, "the familiar C++ syntax." Familiar to whom? Certainly not the
millions upon millions of people who know BASIC. Certainly not the millions
upon millions who know HTML. It was familiar to the select cadre of
engineers at Netscape, along with all of their friends. Did they set out to
be exclusionary? I'm sure not; they just simply adapted the tools with which
they themselves felt comfortable. <<

So, should programmer also "steal POV-Ray"?

>> Would it be fast to parse?
>
> It probably wouldn't be noticeably slower without benchmarking, and
> could possibly allow doing some things in a way that would parse faster
> than previously possible.

Well, I would say it would parse slower because certain access to internal
data structures of POV-Ray would surely take some time.  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!

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

This is a rather provocative question, and I wanted to see someone claim
this would be the reason for the language extension :-)


     Thorsten




[1] "How Programmers Stole the Web" by Bruce Tognazzini
    <http://www.AskTog.com/columns/028WebStealers.html>

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

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

Hmm, you seriously want to call the C++ STL anything else but "spaghetti
code"?  ;-)

Did you consider more abstract Basic-like (READ: in the spirit of ease of
use and learn typical for the average Basic, NOT the syntax style of Basic)
syntax for it?  POV-Ray already has a few hundred keywords, would the ten or
so for a simple built-in implementation really matter compared to the two or
so needed for a C++/Java style implementation allowing references (no
pointers, pleeeeeeeeeeeease!)?

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

Since when does object orientedness improve programming?  How many books,
lectures, labs and practice did you need to master the basics of C++ (not to
mention the basics of object oriented design) compared to the basics of POV?
How many "users" of POV-Ray would really benefit and have the background to
use it?

>   Just think about the possibilities 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).

For whom?  Programmers with a Ph.D. or the average user with perhaps one or
two years of (hobby) programming experience?

namespaces are a problem, but they can be overcome by simple organisational
manners, without the need for a language extension.  Namespaces are merely a
hack to allow programmers not to talk to each other and follow naming
conventions that could be set by a majority vote and central name
registration system!

> : Would it be easier to learn?
>
>   It doesn't matter. You don't have to learn it if you don't want it.

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?

Please read [1], maybe then you understand and leave your tower <sigh>

> : Would it be fast to parse?
>
>   Would it be slower? Does it matter?

Yes (answering your second question).

> :  Would it allow
> : porting C/C++/Java programs to POV-script?
>
>   Why anyone would want to do this? They do different things.

See my note to Chris Huff :-)

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

Hmm, rejecting a jet engine for a car does not imply rejecting a gasoline
engine!  There are features that have more relative value compared to their
cost while others have a lower relative value compared to their (possibly
very high) cost. Note the "relative".


       Thorsten


[1] "How Programmers Stole the Web" by Bruce Tognazzini
    <http://www.AskTog.com/columns/028WebStealers.html>


____________________________________________________
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

Ken <tyl### [at] pacbellnet> wrote:
: Thre were recursive tree include files around before macros were
: introduced. PTDTree for example.

  My point was that it can't be done with a #while-loop.

  Btw, isn't the include recursion level limited to something like 10 in
povray?

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

>   Btw, isn't the include recursion level limited to something like 10 in
> povray?

And won't a very high recursion level crash it when using a macro and a
stack overflow occurs?


    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 <tho### [at] trfde> wrote:
: And won't a very high recursion level crash it when using a macro and a
: stack overflow occurs?

  I'm not sure, but I think that's a compiler-dependant problem. That is,
it depends how big is the stack the compiler makes the program to use.
Some compilers make a laughably small stack (like 16 kilobytes or so).
  Here (in Solaris with gcc) the stack size is something like 2GB and I
don't remember any recursive macro crashing here.

-- 
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:
: Hmm, you seriously want to call the C++ STL anything else but "spaghetti
: code"?  ;-)

  I don't know. From the point of view of the user of the library it has
a pretty clever and abstract interface and the division into modules looks
good.
  I have never looked into the source code of any STL implementation, though.

: so needed for a C++/Java style implementation allowing references (no
: pointers, pleeeeeeeeeeeease!)?

  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.

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

:>   Just think about the possibilities 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).

: For whom?

  From other include files. From the user.

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

:> : Would it be fast to parse?
:>
:>   Would it be slower? Does it matter?

: Yes (answering your second question).

  So if it does matter, then we should remove the #macros. They are very slow.
Specially when included. Also #while-loops are usually slow. What about
big triangle meshes and bicubic patches? They are slow to parse so we should
remove them.

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

: Hmm, rejecting a jet engine for a car does not imply rejecting a gasoline
: engine!  There are features that have more relative value compared to their
: cost while others have a lower relative value compared to their (possibly
: very high) cost. Note the "relative".

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

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