POV-Ray : Newsgroups : povray.general : The Language of POV-Ray : Re: The Language of POV-Ray Server Time
10 Aug 2024 13:20:56 EDT (-0400)
  Re: The Language of POV-Ray  
From: Chris Huff
Date: 30 Mar 2000 07:09:21
Message: <chrishuff_99-07366E.07113830032000@news.povray.org>
In article <38E2CF09.D78C66BE@nigels.com>, nig### [at] eisanetau wrote:

> > >       Show us a "simple little program" to parse POV code.
> > Who said anything about parsing? 
> 
> 	I keeps coming back to this issue which Nick Drew
> 	is aware of - is POV input data, or a program?

Neither, it is a scene description language. Partially input data, 
partially algorithms for making input data.


> 	Having programming is useful,  but also imposes
> 	limitations.

But removing it imposes even more severe limitations.


> > So...loops, macros, and conditionals are things of the past, obsolete,
> > and not needed anymore?
> 
> 	They are not needed for the kind of flexibility
> 	that is being proposed.  It comes down to a
> 	"is it a bug, or a feature?" argument.

What do you mean? This doesn't make any sense.
I don't see how loops, conditionals, and macros can possibly be 
considered bugs. And the reason they were added is because there was a 
need for them.


> > >       That scenario is not what is being suggested.
> > Yes, it is. 
> 
> 	No it isn't, it is ingenuous for you to suggest so.

Yes, it is. Read the message! I went back to it yet another time, and 
couldn't find any other way to interpret it.


> 	Nobody here is making work for the POV team.
> 	Again, you're being intentionally misleading
> 	to suggest it.

How could this be included in the official version without making extra 
work?
I am not being misleading, you just aren't making any sense.


> > POV-Script is even more portable...if there is a version of POV on that
> > platform, your script will run on it.
> 
> 	POV-Script is portable in this sense, but not in the
> 	sense that you can parse your data back from it.
> 	It's a one way street, why not have the option of
> 	a two way street?

This seems to be the only real advantage that POV-XML would have. But it 
isn't that hard to write a parser that supports the basic object syntax. 
Why not do that? Of course, it would be easier to use a separate file 
format and just convert it to POV-Script, but you seem determined to 
read POV files...


> > Not everyone who wants to use POV will want to install and learn to use
> > a C compiler to make their POV scenes. 
> 
> 	Of course not, and that is not what is being suggested.

Show me a way to compile an ANSI C library("An ANSI C compiled library 
is about as portable as it gets.") without a C compiler.
If you weren't talking about using the library to generate a scene 
somehow, what were you talking about?


> > How would XML make the output better?
> 
> 	If it means I can do more in less time, the output
> 	will be better.

How could XML let you do that? The only thing it seems to be capable of 
doing is letting you exchange data between programs, at the cost of 
requiring programs to generate the data.
I don't see how requiring generator programs is any better from 
requiring converter programs.


> > Your point...?
> 
> 	The point is there is no real need to tie people to
> 	one language.

What?


> > You have the option of staring at a screenful of tags trying to decipher
> > the underlying structure or using an external program, you mean?
> 
> 	Exactly.  What's the problem?  Don't like options?

I like the option of hand coding using procedural constructs like loops 
and macros.(and in a way which is actually *readable*) This seems to be 
lost in the POV-XML ideals.


> 	This POV-CSDL suffers limitations of it's own.  Why would 
> 	anyone bother learning YAPL (yet another programming language)
> 	if they had a choice to use whatever fits their environment.

Huh?
I know POV-CSDL has limitations, but I don't see how POV-XML would be 
more limited than it is already if it was implemented in a similar 
way.(as an external translator program)


> 	Personally, I wouldn't be involved in anything that came
> 	under the current POV licensing terms.  This problem
> 	with support of POV is tied to the license.

What does the POV license have to do with this? You don't have to use 
that license for a program that outputs POV code.


> > >       The POV community could use some diversification. :-)
> > Not that kind. All that would do is add confusion.
> 
> 	I think you underestimate the intelligence of people.

What does that have to do with anything I said?
If people are intelligent, they will find the right tool for the job. If 
that means POV-Script, and POV-Script is replaced with POV-XML, they 
will go find another tool. You could have POV-XML support embedded 
POV-Script, but that makes the advantages of POV-XML meaningless, you 
are back to writing a POV parser.

-- 
Christopher James Huff - Personal e-mail: chr### [at] yahoocom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Web page: http://chrishuff.dhs.org/


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.