Bernd Fuhrmann <Sil### [at] gmxde> wrote:
> >   Transform to what?

> POVXML(with a lot of extensions) -> POVXML(with fewer extensions) -> 
> POVXML(with no extensions) -> POVRay SDL -> BMP

  So what you want is a *separate* application which converts your
pov-XML to SDL and then uses POV-Ray to render the image?

  Then why not just go ahead and create such XML specification? Let's see
how much people will be using it...

> >   You have to still remember that the SDL is a programming language, not
> > a document.

> What's the difference?

  By definition in a markup language you have to tell for each distinct
item its type (in XML in the most cumbersome way with starting and
ending tags). An XML parser can then do something with each type
according to some specification of how each type should be interpreted.

  In a programming language you don't need to specify the type of
each item which appears in the program source code. This is because
a programming language is typically not designed so that it can be
parsed with a generic markup parser but needs a parser specific to
that programming language. The advantage of this is, naturally, that
it makes it easier for the user to write programs using this language
because it's the language parser which performs the task of tokenizing
the input, not the user.

  If you write XML by hand you are burdened with this extra task which
should be something the parser does.

  Besides, being a very generic markup language which does not offer
anything specific to any programming language, most programmatical
constructs need to be done either with extremely bloated syntax
where you (not the parser) tell the program for each single item
what it is, or either you use a very artificial syntax of putting
the whole thing into a string (which you should not be required to do
in the first place; just the fact that the quotation marks and other
extra syntax around these strings are not part of the expression should
immediately give you a hint that there's something unneeded there).

  In a programming language you say typically: a=b;
  Now, just think about how you would do that same thing in XML and
how much of that line will be additional bloat which is not really
part of the command but is required by XML. Also think why the user
should write that extra stuff when there's no need.

  The user and the program (in this case POV-Ray) are not interested
in the markup of the input, they are only interested in its meaning.
It just doesn't make any sense to force the user to specify any
markup on the input since none is needed for anything.

> XML offers all these things in one standard that many people know of.

  Can't you understand that XML is not the right tool for writing a
program? Programs are usually written by hand, and this task should be
made as easy as possible.

  What you are suggesting is making the life of the users harder in order
to make the life of the programs easier.

> <sphere center="0,0,0" radius="5"/>

> compare this to:
> sphere {<0,0,0> 5}

  Why should the user be burdened with all that additional syntax?
What does it benefit the user that he is forced to write all those
extra symbols and keywords?

  Besides, that extremely simplistic example is too naive. How would
you write this in XML so that it makes the life easier for someone
(for the user, or the parser, or the renderer or anyone):

union
{ #declare IndX = 0;
  #while(IndX < MaxX)
    #declare IndY = 0;
    #while(IndY < MaxY)
      sphere
      { <IndX*5+1, IndY*0.25-1.25, -5>, IndX*IndY/10
        #if(IndX < MaxX/2)
          pigment { rgb <IndX/MaxX, IndY/MaxY, 0> }
        #end
      }
      #declare IndY = IndY*.125;
    #end
    #declare IndX = IndX*.5;
  #end

  pigment { rgb x } finish { specular .5 roughness .03 }
}

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote:
> > But POVRay 
> > files are rather small. Parsing speed does not matter that much.

> I just wanted to point out this particular statement for those who do 
> not follow this thread very closely...

  Thanks for the ROTFL. I missed that one. :)

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Warp wrote:
> Bernd Fuhrmann <Sil### [at] gmxde> wrote:
> 
>>>  Transform to what?
> 
> 
>>POVXML(with a lot of extensions) -> POVXML(with fewer extensions) -> 
>>POVXML(with no extensions) -> POVRay SDL -> BMP
> 
> 
>   So what you want is a *separate* application which converts your
> pov-XML to SDL and then uses POV-Ray to render the image?

Exactly!

>   Then why not just go ahead and create such XML specification? Let's see
> how much people will be using it...

I can do that, sure. I'd have to spend a lot of time for that. But why 
should I do that if I would become the only user of this specification? 
If one single person (me) works on such a specification it would 
certainly have errors. I need people to correct it and just test it. So 
I thought: "Maybe it's a good idea to search for other people who are 
interested in such a thing for it might prove really useful". That is 
why I posted.
So: Is there anybody interested?

>>>  You have to still remember that the SDL is a programming language, not
>>>a document.
> 
> 
>>What's the difference?
> 
> 
>   By definition in a markup language you have to tell for each distinct
> item its type (in XML in the most cumbersome way with starting and
> ending tags). An XML parser can then do something with each type
> according to some specification of how each type should be interpreted.
> 
>   In a programming language you don't need to specify the type of
> each item which appears in the program source code. This is because
> a programming language is typically not designed so that it can be
> parsed with a generic markup parser but needs a parser specific to
> that programming language. The advantage of this is, naturally, that
> it makes it easier for the user to write programs using this language
> because it's the language parser which performs the task of tokenizing
> the input, not the user.
> 
>   If you write XML by hand you are burdened with this extra task which
> should be something the parser does.
> 
>   Besides, being a very generic markup language which does not offer
> anything specific to any programming language, most programmatical
> constructs need to be done either with extremely bloated syntax
> where you (not the parser) tell the program for each single item
> what it is, or either you use a very artificial syntax of putting
> the whole thing into a string (which you should not be required to do
> in the first place; just the fact that the quotation marks and other
> extra syntax around these strings are not part of the expression should
> immediately give you a hint that there's something unneeded there).
> 
>   In a programming language you say typically: a=b;
>   Now, just think about how you would do that same thing in XML and
> how much of that line will be additional bloat which is not really
> part of the command but is required by XML. Also think why the user
> should write that extra stuff when there's no need.
> 
>   The user and the program (in this case POV-Ray) are not interested
> in the markup of the input, they are only interested in its meaning.
> It just doesn't make any sense to force the user to specify any
> markup on the input since none is needed for anything.

I think I start to get your point. As you observed: I don't think it is 
wise to force anybody to another syntax. I just think there should be an 
alternative. POVRay SDL is ok for a wide range of tasks. But not for all.

So it's basically a trade-off between parser complexity and 
syntax-ease-of-use. But there are cases in which I want to parse a 
POVRay SDL myself, for example to do certain conversions or adaptions. 
If there was some API for that parser my problem would be (almost) 
solved. But there is none. There are still features missing in that damn 
thing and POVRay 4.0 isn't even in development yet. At least I couldn't 
find a bit of information about it except that it is supposed to be 
great and so on; nothing specific. What do you suggest to solve this 
problem? Write an own parser for POVRay SDL? Change POVRay SDL?

>>XML offers all these things in one standard that many people know of.
> 
> 
>   Can't you understand that XML is not the right tool for writing a
> program? Programs are usually written by hand, and this task should be
> made as easy as possible.

I do understand that. But POVRay SDL isn't a full featured programming 
langugage. It seems to me to be comparable to BASIC but not even to 
Pascal or gems like C++. So POVRay SDL has to move on, definately. But I 
don't see that neccessary movement yet.

>   What you are suggesting is making the life of the users harder in order
> to make the life of the programs easier.

Almost right. If you write parsers you will be glad of this.

>><sphere center="0,0,0" radius="5"/>
> 
> 
>>compare this to:
>>sphere {<0,0,0> 5}
> 
> 
>   Why should the user be burdened with all that additional syntax?
> What does it benefit the user that he is forced to write all those
> extra symbols and keywords?
> 
>   Besides, that extremely simplistic example is too naive. How would
> you write this in XML so that it makes the life easier for someone
> (for the user, or the parser, or the renderer or anyone):
> union
> { #declare IndX = 0;
>   #while(IndX < MaxX)
>     #declare IndY = 0;
>     #while(IndY < MaxY)
>       sphere
>       { <IndX*5+1, IndY*0.25-1.25, -5>, IndX*IndY/10
>         #if(IndX < MaxX/2)
>           pigment { rgb <IndX/MaxX, IndY/MaxY, 0> }
>         #end
>       }
>       #declare IndY = IndY*.125;
>     #end
>     #declare IndX = IndX*.5;
>   #end
> 
>   pigment { rgb x } finish { specular .5 roughness .03 }
> }
> 


Hm, interesting example. You might have a 1:1 translation like this:

<union>
<declare l="IndX" v="0"/>
<while cond="IndX<MaxX">
<declare l="IndY" v="0"/>
<while cond="IndY<MaxY">
and so on...
</while>
</union>

You also might also leave it to XSLT to execute your programming stuff. 
That might look like this:

<!-- MaxX and MaxY have to be known at transformation time-->
<xsl:template name="myloopinner">
<xsl:param name="IndY"/>
<xsl:param name="IndX"/>
<xsl:if test="$IndX < $MaxX"/>
<sphere center="$IndX*5+1, $IndY/4-1.25, -5" radius="$IndX*$IndY/10">
<rgbpigment value="$IndX/$MaxX, IndY/MaxY, 0"/>
</sphere>
<xsl:call-template name="myloopinner">
<xsl:with-param name="IndX" select="$IndX"/>
<xsl:with-param name="IndY" select="$IndY/8"/>
</xsl:if>
</xsl:template>

<xsl:template name="myloopouter">
<xsl:param name="IndX"/>
<xsl:if test="$IndX < $MaxX"/>
<xsl:call-template name="myloopinner">
<xsl:with-param name="IndX" select="$IndX"/>
<xsl:with-param name="IndY" select="0"/>
</xsl:call-template>
<xsl:call-template name="myloopinner">
<xsl:with-param name="IndX" select="$IndX/2"/>
</xsl:call-template>
</xsl:if>
</xsl:template>

<union>
<xsl:call-template name="myloopouter"/>
<xsl:with-param name="IndX" select="0"/>
</xsl:call-template>
<rgbpigment and so on>
</union>

This is terrible code. I do hate pure XSLT. There are, however, some 
systems that simplify the use of loops and so on. I just haven't had a 
closer look at them yet. A very promising project seems to be here: 
http://sourceforge.net/projects/xsltsl/

One other thing: I haven't tested this code. It's quite likely that it 
won't work. But I hope you see that it is at least possible. People who 
are used to work with XSLT will most likely find much cleaner and 
simpler solutions.


Besides: Your code is nonsense. 0*0.125 is always 0. Your code will 
either do nothing or never finish.

Regards,
Bernd Fuhrmann

Post a reply to this message

In article <41d6ae1a$1@news.povray.org>, Sil### [at] gmxde says...
> Thorsten Froehlich wrote:
> But POVRay 
> files are rather small. Parsing speed does not matter that much.
> 
Ah.. A real professional user of POV-Ray are we? Some SDL takes longer to 
parse than the actually rendering. The very idea that size, complexity 
and speed in that step is irrelevant is.... incomprehensible..

> Now for the 4.0 rewrite: What will it be like? I just googled a bit, but 
> I couldn't find anything about it. How do you know that similar 
> limitations like the ones described won't appear again? Is there any 
> information about it available?
> 
First off... Thorsten Froehlich is on the development team for this 
program, so one would think he would have a clue what the flaws are and 
why your idea is purely nuts. Yeah, there is one application of XML I can 
think of that provides for programming, but it does so by borrowing the 
<script></script> tags from HTML and using real languages to do the work. 
The rest of it is just parsing of user readable information that defines 
simple behaviours and settings for inbuilt functions, not complex 
objects. It also uses name spaces to keep things straight, but doesn't 
allow directly talking between things in different name spaces. Why? 
Because the same 'include' might be used in several different XML 
plugins. Each of them could use the same function names, the same names 
for objects, etc. and keeping all of them straight, even with namespaces, 
is easier is they never directly interface in any way. The interfaces 
that are supported involve using a unique UID for each one, to make sure 
they don't interfere. With POV-Ray, even with separate spaces, these 
things have to interoperate and coexist. That has to be handled 'by the 
application'.

What form the data takes in the source file has nothing to do with the 
function, only the time wasted a) coding it and b) parsing it. Making it 
intentionally more complex doesn't fix the problem, which is not in the 
file, but in the way the application handles the information. You could 
use bloody Sanskrit on punch cards, Tolkein's elven language transmitted 
by brain waves or even your XML idea and it wouldn't alter the fact that 
the problem is in the limitation of how the data is handled 'in the 
program', not how it is represented in the SDL itself.

Argh.. Its like arguing with someone that insists printing Bible quotes 
on toilet paper would be sacrilegious, it has to be exactly such and such 
font, this specific size, the paper made from only the finest rose wood 
pulp, blah, blah, blah. Only the real argument is if the Reader's Digest 
Condensed version leaving out all the verse names and insisting on 
calling Moses, "the bearded guys with a stick" was the best way to get 
the story across. lol Which is more important, that the program supposed 
the feature everyone admits is missing, or that it was painted in the 
most recent style? BTW, I equate XML with pointillism. Complicated, 
insanely anal and totally pointless if there is a more efficient method 
to solve the problem. Maybe, given 50-60 years it will actually look 
'useful' for some programming applications, much the way pointillism more 
or less accidentally hit on the idea for digital video, years before it 
was remotely practical for anyone without a lot of patience and several 
loose screws to use the idea. However, I strongly suspect it won't. lol

And for the 99,999th time on these news groups. Version 4.0 features are 
not yet even technically 'in development' yet, which makes it a bit hard 
to discuss what or how anything will be implemented in it.... Nor has the 
team expressed a desire to discuss it and have 500 people telling them 
not what will improve the ideas, but how they are doing it all totally 
wrong.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

Patrick Elliott wrote:
> In article <41d6ae1a$1@news.povray.org>, Sil### [at] gmxde says...
> 
>>Thorsten Froehlich wrote:
>>But POVRay 
>>files are rather small. Parsing speed does not matter that much.
>>
> 
> Ah.. A real professional user of POV-Ray are we? Some SDL takes longer to 
> parse than the actually rendering. The very idea that size, complexity 
> and speed in that step is irrelevant is.... incomprehensible..

To be honest: I am not a professional user of POVRay. I just want to 
render some illustrations for my documents and my webpage with POVRay. 
No landscapes, no complex meshes and so on. The sentence you quoted lost 
its context: In MPEG parsing speed is essential. It can make the 
difference if you can watch a movie on a 300Mhz processor or if you need 
a 1000Mhz processor. Assembler optimization is absolutely neccessary for 
such parsers. But in POVRay its different: There is no time limitation 
of that kind. You don't render 25 pics per second, do you? So what if 
you need twice the time for parsing? It won't do that much harm. You 
just have to wait a bit longer or buy a faster computer or simplify your 
scene a bit.

Besides: Parsing is just transforming the program to a treelike internal 
representation form. It's not executing or evaluating the program except 
you do everything with the preprocessor. So does it really take that 
long to process handwritten code? I cannot believe that. It will take 
much longer to execute and evaluate the internal treelike representation.

>>Now for the 4.0 rewrite: What will it be like? I just googled a bit, but 
>>I couldn't find anything about it. How do you know that similar 
>>limitations like the ones described won't appear again? Is there any 
>>information about it available?
>>
> 
> First off... Thorsten Froehlich is on the development team for this 
> program, so one would think he would have a clue what the flaws are and 
> why your idea is purely nuts. Yeah, there is one application of XML I can 
> think of that provides for programming, but it does so by borrowing the 
> <script></script> tags from HTML and using real languages to do the work. 
> The rest of it is just parsing of user readable information that defines 
> simple behaviours and settings for inbuilt functions, not complex 
> objects. It also uses name spaces to keep things straight, but doesn't 
> allow directly talking between things in different name spaces. Why? 
> Because the same 'include' might be used in several different XML 
> plugins. Each of them could use the same function names, the same names 
> for objects, etc. and keeping all of them straight, even with namespaces, 
> is easier is they never directly interface in any way. The interfaces 
> that are supported involve using a unique UID for each one, to make sure 
> they don't interfere. With POV-Ray, even with separate spaces, these 
> things have to interoperate and coexist. That has to be handled 'by the 
> application'.
> 
> What form the data takes in the source file has nothing to do with the 
> function, only the time wasted a) coding it and b) parsing it. Making it 
> intentionally more complex doesn't fix the problem, which is not in the 
> file, but in the way the application handles the information. You could 
> use bloody Sanskrit on punch cards, Tolkein's elven language transmitted 
> by brain waves or even your XML idea and it wouldn't alter the fact that 
> the problem is in the limitation of how the data is handled 'in the 
> program', not how it is represented in the SDL itself.

Right. That is why I suggest to put some processing outside of POVRay. 
POVRay is a good raytracer. I'm really impressed by it's fine 
performance. But I think that not all processing of data should be done 
by POVRay. There are e.g. programs that build meshes out of other data. 
A good example might be the creation of humanoids out of a collection of 
sizes. I will never be able to write anything like human{<0,0,0> 30 40 
10} because I cannot define my own objects. It wouldn't make sense 
anyway if I could because this would lead to total anarchy in the lower 
namespace. But it is still incredible difficult for me to write a parser 
that will just replace all "human {...}" with something that POVRay can 
render like a mesh. That is what I want. I don't want to touch the 
POVRay parser. I just want to get my own preprocessing done. This is 
possible with XSLT (though it sometimes looks ugly, I admit).

> Argh.. Its like arguing with someone that insists printing Bible quotes 
> on toilet paper would be sacrilegious, it has to be exactly such and such 
> font, this specific size, the paper made from only the finest rose wood 
> pulp, blah, blah, blah. Only the real argument is if the Reader's Digest 
> Condensed version leaving out all the verse names and insisting on 
> calling Moses, "the bearded guys with a stick" was the best way to get 
> the story across. lol Which is more important, that the program supposed 
> the feature everyone admits is missing, or that it was painted in the 
> most recent style? 

No, that isn't the point. Example: BASIC is a language that is capable 
of many things. But C/C++ is better. At least for professional 
programmers. No sane man would ever start to write a complex software 
project (like Mozilla or sth similar) with BASIC. So it's not a question 
of style but a question of language features. POVRay SDL lacks a lot 
features I'd like to see. So what do I do? Change POVRay? No! I cannot 
because I don't have the time. I'll rather invent some cool system that 
is able to emulate the features I'd like to have.

 > BTW, I equate XML with pointillism. Complicated,
> insanely anal and totally pointless if there is a more efficient method 
> to solve the problem. Maybe, given 50-60 years it will actually look 
> 'useful' for some programming applications, much the way pointillism more 
> or less accidentally hit on the idea for digital video, years before it 
> was remotely practical for anyone without a lot of patience and several 
> loose screws to use the idea. However, I strongly suspect it won't. lol

Do whatever you like.

> And for the 99,999th time on these news groups. Version 4.0 features are 
> not yet even technically 'in development' yet, which makes it a bit hard 
> to discuss what or how anything will be implemented in it.... Nor has the 
> team expressed a desire to discuss it and have 500 people telling them 
> not what will improve the ideas, but how they are doing it all totally 
> wrong.
> 

Exactly. And that is why I won't base my faith upon it. I never said 
that it should be done this way or that way. I just asked if someone 
would like to design an XML version of the POVRay SDL in order to gain 
customizable proprocessing levels. No change in POVRay was suggested. If 
I did, I apologize.

Besides: If that has been discussed so many times: Why don't you put it 
in the FAQ?

Regards,
Bernd Fuhrmann

Post a reply to this message

In article <41d7e026$1@news.povray.org> , Bernd Fuhrmann 
<Sil### [at] gmxde>  wrote:

> To be honest: I am not a professional user of POVRay. I just want to
> render some illustrations for my documents and my webpage with POVRay.
> No landscapes, no complex meshes and so on. The sentence you quoted lost
> its context: In MPEG parsing speed is essential. It can make the
> difference if you can watch a movie on a 300Mhz processor or if you need
> a 1000Mhz processor. Assembler optimization is absolutely neccessary for
> such parsers. But in POVRay its different: There is no time limitation
> of that kind. You don't render 25 pics per second, do you? So what if
> you need twice the time for parsing? It won't do that much harm. You
> just have to wait a bit longer or buy a faster computer or simplify your
> scene a bit.
>
> Besides: Parsing is just transforming the program to a treelike internal
> representation form. It's not executing or evaluating the program except
> you do everything with the preprocessor. So does it really take that
> long to process handwritten code? I cannot believe that. It will take
> much longer to execute and evaluate the internal treelike representation.

Sorry, but you just disqualified yourself. There is no point to continue
this whole thread based on your current knowledge.

    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

Bernd Fuhrmann <Sil### [at] gmxde> wrote:
> But POVRay SDL isn't a full featured programming langugage.

  What is, in your opinion, a "full featured programming language"?
  The SDL is turing-complete.

> and so on...

  Exactly my point. Too tedious to write?

  Besides, you conveniently skipped the hard parts of the code, for
example the conditional inside the sphere.

  What good does it do to simply put the code into quotation marks and
add some extra junk around them? That doesn't help the user nor the
program trying to interpret the code (it simply gets the code as a
bunch of strings which it has to parse and interpret anyways, without
the help of any XML parser).

> Besides: Your code is nonsense. 0*0.125 is always 0. Your code will 
> either do nothing or never finish.

  Besides the point. It was just an abstract example. Set the initial
values to 1 if you want to feel better about it. ;)

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Warp wrote:
> Bernd Fuhrmann <Sil### [at] gmxde> wrote:
> 
>>But POVRay SDL isn't a full featured programming langugage.
> 
>   What is, in your opinion, a "full featured programming language"?
>   The SDL is turing-complete.

Yes, it is. There are a lot of features missing that are used in a lot 
of modern programming languages. Examples:
* Structs/Classes
* References, esp. to functions
* Namespaces
* strict type checking

Other possibly cool features
* Inheritance
* Java-like classes inside classes
* C++ like multiple inheritance
* Lambda expressions (Scheme)

>>and so on...
> 
> 
>   Exactly my point. Too tedious to write?

Well, yes. But I'm even more tedious to rewrite that POVRay parser.

>   Besides, you conveniently skipped the hard parts of the code, for
> example the conditional inside the sphere.

Ooops. Sorry for that. What you're missing is this:
[...]
<sphere center="$IndX*5+1, $IndY/4-1.25, -5" radius="$IndX*$IndY/10">
<xsl:if test="$IndX<MaxX/2">
<rgbpigment value="$IndX/$MaxX, IndY/MaxY, 0"/>
</xsl:if>
</sphere>
[...]

But as I just found out: XSLT won't be able to do all transformations 
that POVRay would be able to do, since POVRay knows sometimes more about 
objects (like max_extent) and so on. Sorry for not knowing this.

Still, this does not solve those namespace and data access problems. 
There still needs something to be done. I just have to think about 
another way...

>   What good does it do to simply put the code into quotation marks and
> add some extra junk around them? That doesn't help the user nor the
> program trying to interpret the code (it simply gets the code as a
> bunch of strings which it has to parse and interpret anyways, without
> the help of any XML parser).

XSLT can process it. Nothing more nothing less.

>>Besides: Your code is nonsense. 0*0.125 is always 0. Your code will 
>>either do nothing or never finish.
> 
> 
>   Besides the point. It was just an abstract example. Set the initial
> values to 1 if you want to feel better about it. ;)

Ok, never mind.

I must admit that using XML/XSLT exclusively for scene design and 
parsing is mad. But on the other hand I will still require a SDL that 
has more features, with configurable preprocessing levels. To give you a 
nice example: What about a JavaDoc/Doxygen-like processing? Wouldn't 
that be cool?

Regards,
Bernd Fuhrmann

Post a reply to this message

Darren New wrote:
> Bernd Fuhrmann wrote:
> 
>> Yes, it is. There are a lot of features missing that are used in a lot 
>> of modern programming languages. Examples:
>> * Structs/Classes
>> * References, esp. to functions
>> * Namespaces
>> * strict type checking
> 
> 
> There are plenty of large high-performance production servers as well as 
> end user desktop software written in languages that lack most or all of 
> these features. Their lack doesn't make programming languages "not real".
> 
>> <xsl:if test="$IndX<MaxX/2">
> 
> 
> The problem with doing something like this is, you then get to ask a 
> question like "transform this scene to remove items that fail this 
> condition."  How about "select in this scene objects that don't 
> intersect the sphere"?

This is not possible without giving XSLT some information about what a 
sphere is. This is possible, but it will get

> If you're not going to code everything in XML, anything you don't code 
> in XML is going to be opaque to whatever transforms you want to do. You 
> won't even be able to say "shift this element 10 units right."

Right.

>> Still, this does not solve those namespace and data access problems. 
>> There still needs something to be done. I just have to think about 
>> another way...
> 
> Write a parser for SDL. Since the help files describe the SDL using 
> basically BNF notation, you can use yacc/bison to write a parser for it. 
> I'm not understanding why it would be difficult, unless the docs don't
> match the reality, in which case you have a bug report. I mean, you
> even get the source to an existing parser, yes? :-)

I could write my own parser, sure. But that wouldn't fix the problem. 
I'd still have unprocessable code.

As mentioned earlier: I will have to think about something different to 
solve my problem. XML is a solution but due to certain limits of XSLT 
not the best one.

Regards and thanks for all your comments,
Bernd Fuhrmann

Post a reply to this message

This thread was intersting to read.
I think you guys both (Warp, Bernd) made the point.
I really did think that xml might be more universal way to code.
Povray is just very specific and only for 3d modeling.
But then you realize all the drawbacks... XML is really bloated and less 
convenient to read and code, no doubts, even though it may have some 
advanced features, which most of people will use very rarely.
It took me 3-4 days to learn and start understanding Povray codings, but 
xml I'm not sure at all. For me it would be annoying even to always 
write < /> and at the same time it is really easy to learn Povray (if 
you familiar with progr. languages).

Another point made by Bernd and he is right that Povray SDL indeed needs 
more features to be implemented, I very much support his idea about
1.Namespaces
2.Classes and inheritance
3.References
So you see closer to C++ cooler:)

And they should be easier and more intersting to implement than to write 
another parser (for the language which standart may change). Sure that's 
a heck of a work, but eventually it should be done.
I'd love too see some of these features in the next version of Povray.

Andrey Skvortsov

Post a reply to this message