> It is complex to parse, but parsing isn't the only thing that is
> important. 

	You're right - parsing is not the only important
	thing - but it is important.

> And I really don't see why I would want to use Internet Explorer(or any
> web browser) to parse POV scripts or edit POV scripts with a web page.

	Internet Explorer is capable of displaying an XMLish POV
	script in "traditional" POV script, complete with syntax
	highlighting.  Alternatively, you could display it in
	whatever notation makes the most sense.  The important
	point is that many applications will be able to work with
	XML, whereas not many applications will ever be able to 
	work with POV Script, except as ASCII text.

> I guess we have different priorities. I(and apparently most people here)
> want a language which is more flexible and easier to read than the
> current POV-Script, and you want a language which you can write a parser
> for more easily.(or use an existing parser for)

	XML is more flexible than POV Script.   One way to keep 
	everyone happy, would be to provide a translation layer
	from POV script.  It's a better design than having a
	monolythic parser that tries to be everything to everyone.
	
> And for the majority of extensions, you would still have to modify the
> POV source code.

	Yes, but these changes would be much simpler.

> Writing POV from a program is easy

	Yes, but once in POV script, you can't do anything else
	with it.

> That is why I am working on POV C-SDL! Which happens to be human
> readable-writable. :-)

	What I've seen of POV C-SDL looks quite nice.
	Do you think this should be layered on top of
	POV, or compiled straight into the binary?
	(Where do I find docco on POV C-SDL?)

> Do you think there is no reason the most popular programming languages
> are designed the way they are? The "flat text" format happens to be
> quite versatile, and human *creatable* and human *readable* instead of
> something that can only be tweaked by hand and which has to be generated
> and read by a program.

	Programmers are quite familiar with the strengths and
	weaknesses of using flat text.  There is not reason that
	programming languages should have to be this way. To
	limit your imagination to this way of doing things is
	unnecessary.

> You seem to define language differently from everyone else. A language
> is more than the data model it represents. Otherwise, Pascal and C could
> be considered the same language. XML would let *programs* manage the
> data more effectively, but would greatly restrict what humans can do.

	Pascal and C are nearly equivalent languages.  They are
	basically the same technology.  The fact that it's
	possible to generise away from either Pascal and C
	and provide translation to either - is a powerful idea.
	
	The point here is the exact format expected by a particular
	compiler (say C or Pascal) is not as important as the 
	struture of the underlying data that you're feeding it.
	XML captures this data, while being generic about the
	formatting.

> What cross-platform GUI tools are you referring to?

	A few off the top of my head:

	V is a cross platform C++ library for GUI's
	Qt is the basis for the KDE project
	Gtk is the basis for Gnome, and is being ported to windows
	Java
	There are quite a few other options.

> It will be a long time until a (graphical) tool is available on
> all the platforms POV runs on. 

	I don't think it's as big an issue as you believe it is.

> Many people would probably give up on POV before then...

	I think that as long as people still have POV script
	as an option, they are not going to be concerned with
	the underlying technology used for implementation.

> Just don't forget that it won't keep developing if everyone stops using
> it because of a poor design choice.

	I think that using POV Script as _the only_ way to get
	data into POV is a worse design choice.  

--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.

Post a reply to this message

In article <38CD7C45.38B53962@nigels.com>, nig### [at] eisanetau wrote:

> 	XML is more flexible than POV Script.   One way to keep 
> 	everyone happy, would be to provide a translation layer
> 	from POV script.  It's a better design than having a
> 	monolythic parser that tries to be everything to everyone.

So what exactly are you suggesting? That POV should use XML for data 
representation and should internally convert POV-Script to XML as well 
as supporting XML input?


> > And for the majority of extensions, you would still have to modify the
> > POV source code.
> 
> 	Yes, but these changes would be much simpler.

Not necessarily. It is pretty easy to add parsing code for most 
features, and it should get a lot easier in POV 4.0 after the planned 
conversion to C++.


> 	Yes, but once in POV script, you can't do anything else
> 	with it.

I really don't know what you mean by that...


> 	What I've seen of POV C-SDL looks quite nice.
> 	Do you think this should be layered on top of
> 	POV, or compiled straight into the binary?
> 	(Where do I find docco on POV C-SDL?)

I posted a description of my concept in .off-topic. It would be 
translated by a separate program into POV-Script, either by converting 
loops, conditionals, etc. to POV-Script syntax or by executing the C-SDL 
code and outputting the objects and scene settings. Eventually, it might 
be included as an actual feature of POV, but it would probably be wise 
to wait for most of the problems to be worked out of it(of course, a 
parser/converter has be be written for it before that can start. I am 
making an attempt, but would welcome any help anyone would want to 
give.).


> 	Programmers are quite familiar with the strengths and
> 	weaknesses of using flat text.  There is not reason that
> 	programming languages should have to be this way. To
> 	limit your imagination to this way of doing things is
> 	unnecessary.

But is it actually limiting? I don't feel very limited...can you give an 
example?
BTW, have you ever heard of the ProGraph programming "language"? Just 
wondering...


> 	Pascal and C are nearly equivalent languages.  They are
> 	basically the same technology.  The fact that it's
> 	possible to generise away from either Pascal and C
> 	and provide translation to either - is a powerful idea.

But they are separate languages. They can both be used to express the 
same idea, but they are different things. Just as English and Spanish 
are different human languages, they can both express the same "data", 
but are clearly separate languages.


> 	The point here is the exact format expected by a particular
> 	compiler (say C or Pascal) is not as important as the 
> 	struture of the underlying data that you're feeding it.
> 	XML captures this data, while being generic about the
> 	formatting.

The problem is that it is too generic, it can't be hand-edited easily. 
Special tools are required.
It is more of a file format than an actual language...


> > What cross-platform GUI tools are you referring to?
> 
> 	A few off the top of my head:
> 
> 	V is a cross platform C++ library for GUI's
> 	Qt is the basis for the KDE project
> 	Gtk is the basis for Gnome, and is being ported to windows
> 	Java
> 	There are quite a few other options.

And these will let me create and edit files written in this XML-POV 
without being exposed to the XML "syntax"? Or they will let me write 
programs that use XML?


> 	I don't think it's as big an issue as you believe it is.

I think it is. If I don't have the required tools, I can't use it.


> 	I think that as long as people still have POV script
> 	as an option, they are not going to be concerned with
> 	the underlying technology used for implementation.

I think I see what you mean now...some kind of XML-based interpreter 
that can read POV-Script as well as XML?


> 	I think that using POV Script as _the only_ way to get
> 	data into POV is a worse design choice.  

Why isn't POV-Script a good way of getting data into POV? The only 
information absolutely required is the objects and things like 
global_settings, background, etc. A program can just "run" a scene 
described in another language and output the data in POV-Script.
I don't understand this "flexibility" argument, at some point it has to 
be converted into data structures in RAM. The only thing that would make 
adding features easier would be the universal syntax, and that could be 
done in other ways just as well.

Whatever you think, I am not against XML. I think it is a great idea for 
many things, just not the right tool for POV.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

"Nieminen Juha" <war### [at] sarakerttunencstutfi> wrote in message
news:38ccad49@news.povray.org...
> Matt Giwer <jul### [at] ijnet> wrote:
> : Everything in computing can be done with the minimalist set of
> : micro-code which actually gets down to four or five instructions
> : depending upon your side in the debate
>
>   Actually 2 instructions are enough.

"on" and "off" ?  Programming in pure binary, are you?
rc

Post a reply to this message

On Fri, 10 Mar 2000 12:21:22 +0100, Axel Baune
<aba### [at] neuroinformatikuni-ulmde> wrote:

>Hello,
>
>PoD wrote:

>> Then use a while loop and nothing is lost, except that you've made your
>> script hard to read.  There's probably an easier way to do it using
>> for()
>
>No, you couldn't do everything with a for-loop what you could do with a
>while-loop. The while-loop is far more flexible, beacuse the for-loop is
>a special case of the while-loop for cases where _one_ variable is
>looped through a range of values with a constant step width. 

Did the man say he wanted to *replace* the while-loop, or does he
perhaps want to supplement the while-loop with a for-loop? I see
nothing wrong with having a for-loop in POV. For many situations, it
would be easier for newcomers to understand and it would work
perfectly. The for-loops I have used in the past have also allowed a
STEP parameter that defined the amount of increment for each loop. One
wouldn't have to be limited to incrementing or decrementing by one.


Later,
Glen Berry

Post a reply to this message

On Thu, 09 Mar 2000 19:13:21 -0500, Chris Huff
<chr### [at] yahoocom> wrote:

>Still, my first point was a platform specific editor feature is no 
>substitute for a language feature.

Whos said anything about a platform-specific editor? 

There must be something I am overlooking here. Aren't programs that
deal with ASCII text some of the most easily portable programs? Why
does a POV scene editor ( not a modeler, mind you ) have to rely on a
lot of platform specific coding? I'm sure someone will be quick to
remind me of the reason I seem to have forgotten.

Later,
Glen Berry

Post a reply to this message

On 9 Mar 2000 19:53:59 -0500, ron### [at] povrayorg (Ron Parker)
wrote:

>There are other reasons to prefer += in a case like that.

I'll admit that I didn't understand the usefulness of this until you
explained it so well.

Later,
Glen Berry

Post a reply to this message

On Sat, 11 Mar 2000 22:42:04 -0500, Chris Huff
<chr### [at] yahoocom> wrote:

>Remember though, that POV-Ray is created by people in their free time. I 
>wouldn't want them to delay the releases so documentation like that 
>could be written. 

I think that the documentation could be improved quite a bit, even
without going into more complex aspects of scene creation. More
illustrations would be a good start.

As for custom-patched versions of POV, every new patch should come
with multiple examples of each new keyword and concept that are
introduced. If the patch is available for Windows, then appropriate
insert-menu addtions should be offered with the patch as well.

>> And it would be nice if POV-Ray had some sort of plugin architecture

>This is a nice idea, but would be nearly impossible to implement.

I'm not a serious programmer, but I've always thought that the main
obstacle to plugins was the attitude of the POV-Team being against
such things. I thought some people had already proposed workable ideas
for implementing plugins, but the POV-Team firmly refused the concept.
Mind you, I don't dare say that it would be easy to add plugins, but I
think it should be possible somehow.

Even POV itself can't be simply compiled on every platform it is used
on, without some porting work performed by talented human programmers.
If this were not the case, then why is there a Mac specialist, a Linux
specialist, a Windows specialist, etc? It took a long time to get a
Linux port of a recent POV version. If POV were perfectly
cross-platform, then there wouldn't have been the wait.

Also, need I remind everyone that the various ports of Official POV
have  different feature sets? The Windows version has a built-in
editor with color-syntax highlighting. I think the Mac version has
QuickTime support. The DOS version has neither.

I think that a plugin system could be devised. Instead of simply
dropping a plugin written for an Intel/Windows machine into a Silicon
Graphics machine running UNIX, one might have to port the plugin the
same way that POV itself is ported. It might even turn out that some
plugins might behave slightly different on different platforms, or
perhaps not be available at all on some platforms. This would be
acceptable to me, as long as everyone realized that plugins were to be
considered *options* and not part of the base functionality of POV
itself. 

I don't hear people saying that 'Photoshop shouldn't use plugins
because not all plugins are available on all platforms'. In fact,
plugins are a vital part of Photoshop's appeal for many people, in
spite of the fact that some plugins aren't available on some
platforms.

Later,
Glen Berry

Post a reply to this message

On Mon, 13 Mar 2000 17:50:40 -0500, Chris Huff
<chr### [at] yahoocom> wrote:

>In article <38CCF223.EE4E8A91@nigels.com>, nig### [at] eisanetau wrote:
>
>> 	All I want to see here is some more brainstorming
>> 	going on.  If povray is still available in 2050,
>> 	it will only be because it keeps evolving.
>
>Just don't forget that it won't keep developing if everyone stops using 
>it because of a poor design choice.

Poor design choices haven't stopped it yet.    :)

...and yes, there *have* been at least a few poor design choices.

I say if someone has the ability to write an XML based POV, more power
to them. It would be nice to actually have such a program to test,
instead of just speculating about it. You won't often find me
discouraging experimentation with new ideas. It's often the more
unusual ideas that end up being the most enlightening. Even if an idea
never makes it into mainstream use, there is often still be a place
for it, or it might lead to bigger and better things, as yet
unforseen.

Later,
Glen Berry

Post a reply to this message

Chris Huff wrote:

	Pardon for deleting all of yours but this is my issue. 

	If syntax is extended then those issues will have to be
addressed. That is my point. One simple routine that can do
everything is quite good enough. 

-- 
A free internet for a free people.

Post a reply to this message

On Mon, 13 Mar 2000 20:46:03 -0500, Chris Huff
<chr### [at] yahoocom> wrote:

>Not necessarily. It is pretty easy to add parsing code for most 
>features, and it should get a lot easier in POV 4.0 after the planned 
>conversion to C++.
>
>
>> 	Yes, but once in POV script, you can't do anything else
>> 	with it.
>
>I really don't know what you mean by that...

You've been saying that a lot lately, but still you seem content to
judge that which you don't understand.

His point was the POV-Script isn't very easy for another program to
parse. Why would you want to parse POV code with another program? It
would be handy for 3rd party file format converters, modelers,
editors, object generators, and more. Several people have wanted to
write some cool utility programs. but were stopped cold at the
prospect of writing a parser that understood POV code flawlessly. It
would be possible to do, but in many cases, it would be harder than
writing the actual utility program it was to be used with.

Later,
Glen Berry

Post a reply to this message