|
 |
In article <38CCF223.EE4E8A91@nigels.com>, nig### [at] eisa netau wrote:
> I'm going to stand by this. Whether it is braces, tags,
> commas, dots or my favorite character ~ , it is not
> too important.
Maybe not to the computer, but to the person reading and writing it
there is a huge difference.
Are you saying that:
<STATEMENT>PARAMETERS</STATEMENT>
is as easy to understand as:
STATEMENT {PARAMETERS}
even when you have deeply nested complex statements? That is how I
understood what you were saying...
Hmm, the tilde character(~) as a block character... :-)
> Backwards? Consider the fact that POV Script is complex
> to parse. How many applications can parse it? Not many.
> In XML, Internet Explorer 5 can parse pov script. Think
> about it. With another layer, Internet Explorer 5 could
> build a HTML page with a bunch of edit boxes that allow
> editing. Or syntax highlighting, or whatever.
It is complex to parse, but parsing isn't the only thing that is
important. The language is useless if you can't write it and understand
what is already written.
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.
This might be useful for some things, but I don't see how it applies to
POV-Ray. Could you please explain further?
> > How is that so?
>
> There are two ways to write software. One is to do
> everything yourself, as you please. Another is to make
> use of the work of others - libraries, standards, file
> formats, technology trends. Povray relies on quite a
> large and complex parser, implemented in C. To extend
> Pov Script, you have to mess with the C parser. To
> extend an XML based file format, you edit the DTD
> (basically, the grammar) and add handlers for the
> intermediate representation made available from the
> XML parsing module. Adding new tags in a way that
> doesn't break backwards compatibility is straight-
> forward.
And the costs would be code that only a machine could read and which has
to be written with the aid of a complex piece of software.
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)
And for the majority of extensions, you would still have to modify the
POV source code.
> I would like to be able to write applications which
> import and export POV compatible data - but I can't.
> Pov script simply isn't easy to parse, only POV can
> do it, and this is a handycap.
Writing POV from a program is easy, and it is easy to read and write
data that can be read and written by POV. That is one of the things the
file input-output commands were added for.
Have you tried outputting data into a plain text file and reading it
with POV macros?
> I think this whole "POV as programming environment"
> is neat, but should be allowed to evolve in different
> directions on top of something more solid than a
> tangle of C parser code.
What exactly are you talking about?
> The current parser was state of the art, for it's
> time. It's served us well, and it's been pushed
> to it's limits. Is it conceivable that it is
> time for an alternative?
That is why I am working on POV C-SDL! Which happens to be human
readable-writable. :-)
> True, my assumption is that people ultimately want
> more powerful and intuitive tools than a flat text
> editor. XML is something is perhaps somewhere
> between being "human editable" and "machine processable"
> and I think that is a good balance for POV to find.
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.
> Not at all, you seem to get the impression that this is
> a new language - it's not. It's simply POV Script in an
> XML form.
While it may not be a "new" language, it is definitely a different one.
It is an XML representation of POV-Script, not POV-Script.
> There are two issues here - (1) the data model,
> and (2) the way you encode it in ASCII. I am really only
> referring to (2). The whole point of XML is to allow you
> to manage the data model more effectively - but it doesn't
> mean that you throw away your existing data model to use XML.
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.
> I did specifically say "mesh data aside". And POV is
> a terrible way to store meshes - seriously, even VRML
> is more compact than Pov Script. Adding Indexed Face
> Set meshes to POV would be one of the first "cool"
> extensions that would be more easily done in XML.
> (Partly because we can borrow the XML DTD for VRML
> indexed face set, and be guaranteed compatibility)
Sorry, I goofed, I didn't notice you said that. But you have to admit it
is a big problem, and if you are using the VRML format, even you have to
admit it isn't POV script.
> OK, here goes, digging up a random macro to implement:
>
> </macro>
> <name> TextLabel</name>
> <param>Text </param>
> <param>Position </param>
> <body>
> <text no_shadow="true">
> <ttf>timrom.ttf <var>Text</var> 0.1 0 </ttf>
> <translate> <var>Position</var> </translate>
> </text>
> </body>
> </macro>
Yeargh! That is awful! :-)
And what about loops and conditionals?
Try this:
#macro TextLabel(Text, Position)
text {ttf "timrom.ttf", Text, 0.1, 0
no_shadow
translate Position
}
#end
Do you really claim they are both as easy to read?
BTW, here would be a theoretical C-SDL version(using a slightly updated
syntax from what is posted in .off-topic:
function object TextLabel(string Text, vector Position)
{
return text {
font_name = "timrom.ttf";
text_string = Text;
has_shadow = no;
transforms.translate(Position);
};
};
> Program code is structured data, after all!
> Granted, it's not as easy to read as POV Script,
> but converting to/from this to a syntax highlighted
> POV Script version should be reasonably easy.
Syntax highlighting can be done now. I know, since both the official Mac
version and MacMegaPOV do it. And the Windows editor apparently does
too. I don't know about the Linux versions, but I assume they have
similar features.
> It would certainly be a nice feature, regardless of
> the actual scene decription format. And with more
> cross-platform GUI tools becoming available, portability
> no longer means text-only editing.
What cross-platform GUI tools are you referring to?
With plain text human-readable code, you can edit it with whatever text
editor you want, and there are many of them for each platform, some with
very powerful macro and scripting capabilities of their own. It will be
a long time until a similar variety of that type of tool is available on
all the platforms POV runs on. Many people would probably give up on POV
before then...
> Anyway, I don't see the need to be so hostile.
Sorry, I don't mean to appear that way.
> 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.
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
