Well, I've thought of a couple of potential uses.  My overall goal is trying
to build a render farm program, and there are some tricky points.  One of
the things I am trying to do is determine all the resource files needed by a
POV-Ray scene file.  Things like #include files, and image files for
mappings and such.  To some degree even resources where the name is
generated at parse time could be figured out, unless some super complicated
method is used (like using a function or something).  Also, if done right
you could add syntax which could be parsed and rewritten in standard POV
SDL.  For example adding a #for statement, that gets rewritten as a #while.
It wouldn't be something most people would want to do, but it might make my
life easier sometimes. :-)

AW

Post a reply to this message

In article <3e1b06b8$1@news.povray.org> , "Vadim Sytnikov" <syt### [at] rucom>
wrote:

> What (I think) would be indeed highly useful are lex/flex and bison/yacc
> conunterparts with licenses more open than GPL. In fact, a good FSM-based
> parser is what POV-Ray is currently missing badly, IMHO.

No, that isn't correct.  You should not make such bold claims without
profiling the code first!  And this issue has been discussed often in the
past.

    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 <BA410C8C.8D7C%fid### [at] artrecognitioncouk> , Fidel viegas
<fid### [at] artrecognitioncouk>  wrote:

> http://www.cs.princeton.edu/~appel/modern/java/CUP/.

<http://www.cs.princeton.edu/~appel/modern/>

Given that this link goes to a subpage of one of the worst introductory
compiler construction books ever written*, content of that site cannot
really be considered credible or reliable!

    Thorsten



* It is written using writing techniques of those "Learn X in 21 days
books".  All three editions are copy and paste of the other editions, with
all errors.  Completely ignoring language specialties on the implementation
side, with neither head or tail to either the C or Java books (haven't read
the ML edition yet, and don't plan to do it).  Examples contain more errors
that correct lines (referring to the 1st C edition).  And the book does a
great job obscuring the important stuff while setting focus on irrelevant
aspects in the theory sections.  In short 544 pages of overpriced paper with
ink sprinkled on it.

____________________________________________________
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 <3e1c9c02@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

> No, that isn't correct.  You should not make such bold claims without
> profiling the code first!  And this issue has been discussed often in the
> past.

Profiling?
I thought he was talking about the ability to create a grammar for other 
people to use without having to use POV source code, and ease of parser 
creation/maintenance. Does profiling have some use other than 
performance tuning?

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Christopher James Huff wrote:
>In article <3e1c9c02[at]news.povray.org>,
> "Thorsten Froehlich" <tho### [at] trfde> wrote:
>
>> No, that isn't correct.  You should not make such bold claims without
>> profiling the code first!  And this issue has been discussed often in the
>> past.
>
>Profiling?
>I thought he was talking about the ability to create a grammar for other
>people to use without having to use POV source code, and ease of

No, he implied that POV-Ray is missing a fast parser in the part I quoted.

Regarding a grammar: Grammars in a format assuming a specific parser
generator are hardly very useful. And formal grammars cannot be directly
read by any parser generator. So no need for yet another grammar format,
POV-Ray already uses its own (informal one) in the documentation.

    Thorsten

Post a reply to this message

I do have to say, that the documentation does a great job of defining very
clearly the exact syntax POV uses.  It really does.

AW

Post a reply to this message

Thorsten Froehlich wrote:
> In article <BA410C8C.8D7C%fid### [at] artrecognitioncouk> , Fidel viegas
> <fid### [at] artrecognitioncouk>  wrote:
> 
> 
>>http://www.cs.princeton.edu/~appel/modern/java/CUP/.
> 
> 
> <http://www.cs.princeton.edu/~appel/modern/>
> 
> Given that this link goes to a subpage of one of the worst introductory
> compiler construction books ever written*, content of that site cannot
> really be considered credible or reliable!

I do agree that the book isn't that good, but the link wasn't meant for 
the book, but for the parser generator. I personally, do not use it, I 
just gave a couple of links of parser generators I know. I use ANTRL 
(which generates code for C++, C# and other languages as well as Java) 
and  SableCC.

All the best

Fidel.

PS: The bible for compiler writing is the dragon book (Compilers: 
Principles, Techniques and Tools, by Alfred Aho), no doubt about it.

Post a reply to this message

On Wed, 08 Jan 2003 10:54:48 -0500, Andrew Wilcox quoth:

> Well, I've thought of a couple of potential uses.  My overall goal is
> trying to build a render farm program, and there are some tricky points.
>  One of the things I am trying to do is determine all the resource files
> needed by a POV-Ray scene file.  Things like #include files, and image
> files for mappings and such.  To some degree even resources where the
> name is generated at parse time could be figured out, unless some super
> complicated method is used (like using a function or something).

The Parse_String() macro will probably trip any such program up.  It not
only generates the names of the files it includes at runtime, it also
generates the files themselves at that time.

-- 
Mark

Post a reply to this message

"Thorsten" <nomail@nomail> wrote:
> No, he implied that POV-Ray is missing a fast parser in the part I quoted.

Correct.

> Regarding a grammar: Grammars in a format assuming a specific parser
> generator are hardly very useful. And formal grammars cannot be directly
> read by any parser generator.

Now it is I that have to say that your statement is too bold without trying
to express POV-Ray's grammar in yacc. Did you do that? I have to admit that
I did not do that either, but my great experience in the area of compilers'
construction suggests that POV's *formal* grammar might as well turn out to
be the *working* one. Here, I imply nothing about its performance, just more
or less "direct use". But -- see below.

Yacc's/Bison's grammar is as close to BNF as it could probably be. So, if I
got you right, you implied that before a grammar could be made unambiguous
it would have to be transformed (in an attempt to resolve reduce-reduce
conflicts; shift-reduce are generally OK; here, I imply bottom-up analysis,
of course) to such a degree that it would become virtually unusable for a
human reader (e.g. one of those creating third-party SW to use with POV)?

I disagree. My point is that (i) POV-Ray's SDL structure is very linear, and
(ii) the number of reserved words it currently has suggests that performance
gain from using an FSM-based *scanner* would be even greater than the
languages with far fewer nmbers of keywords enjoy (e.g. C/C++).

The golden mean between your and my approaches would probably to make an
FSM-based POV SDL scanner (which *would* make difefrence, I swear) but leave
parser intact.

Post a reply to this message

In article <3e1d1b30@news.povray.org> , "Vadim Sytnikov" <syt### [at] rucom>
wrote:

> Now it is I that have to say that your statement is too bold without trying
> to express POV-Ray's grammar in yacc. Did you do that? I have to admit that

I know yacc and I know the POV-Ray grammar.  That is enough for me to not
try it myself.

> I disagree. My point is that (i) POV-Ray's SDL structure is very linear
<snip>
> languages with far fewer nmbers of keywords enjoy (e.g. C/C++).

I agree with you that POV-Ray is different from programming languages in
this regard.

> The golden mean between your and my approaches would probably to make an
> FSM-based POV SDL scanner (which *would* make difefrence, I swear) but leave
> parser intact.

You should really profile the code.  Then you would find that the matching
of keywords isn't the bottleneck at all.  The simple way of reading from
file is the real problem.  Make the fgetc and ungetc ten times faster and
you end up with a much faster parser.

    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