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

"Thorsten Froehlich" <tho### [at] trfde> wrote:
> 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.

In this respect, I can suggest an easy, virtually free (in terms of efforts)
solution: (i) use getc() instead of fgetc(), and (ii) always #include
<stdio.h> in the modules that use getc(). In such a case, you end up using
very efficient macro instead of a function; five to ten times or so as fast;
no side effects. This is an ANSI behaviour, not a VC/GCC/etc. hack.

I am still a bit suspicious as to the real bottlenecks though... but you're
right, there is no point in arguing w/o profiling it. One day I will do this
again, for sure... As you did read my povpro info, you should be aware that
I did that (profiling) in the past, but I have to admit that I did not pay
any attantion to parsing step at the time, at all. Well, one day, when I
have enough time on my hands...

Post a reply to this message

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

> In this respect, I can suggest an easy, virtually free (in terms of efforts)
> solution: (i) use getc() instead of fgetc(), and (ii) always #include
> <stdio.h> in the modules that use getc(). In such a case, you end up using
> very efficient macro instead of a function; five to ten times or so as fast;
> no side effects. This is an ANSI behaviour, not a VC/GCC/etc. hack.

This is only true for ISO C, not ISO C++.  In C++ all C macros are required
to be functions; and when using "cname" instead of "name.h" headers they are
even placed in the std namespace.  POV-Ray 3.5 is a C++ program.

Apart from that the lastest revision of C, ISO C 99 explicitly notes that
getc may be either a function or a macro.  In reality, it is even so that
some libraries implement it in terms of exactly the same code fgetc uses...

> I am still a bit suspicious as to the real bottlenecks though... but you're
> right, there is no point in arguing w/o profiling it. One day I will do this
> again, for sure... As you did read my povpro info, you should be aware that
> I did that (profiling) in the past, but I have to admit that I did not pay
> any attantion to parsing step at the time, at all. Well, one day, when I
> have enough time on my hands...

Takes a scene that takes relatively long to parse like isocacti.pov and
render only a very small image.  You still get some trace and isosurface
stuff in there, but still the result will be clear.

    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