"Vadim Sytnikov" <syt### [at] rucom> wrote in message
news:3c8f298c$1@news.povray.org...
> "Thorsten Froehlich" <tho### [at] trfde> wrote:
> > ...if you don't see it you never looked into the POV-Ray source
> > code nor the concept of these directives.
>
> If a language has an explicit pre-processing stage, then there is
something
> wrong with the language itself. My point is that POV-Ray must not expose
> that to the user -- and hopefully get rid of such internal subdivision as
> well.

The explicitness of a preprocessing stage has nothing to do with the
language itself.  For instance, MSVC will automatically, preprocess, compile
and link objects all in one step.  gcc on the other hand, has separate tools
for preprocessing, compiling, assembling, and linking (though you have a
common 'control' file to do it all at once).  In one of them, it is very
explicit; in the other, it is implicit.  But they both work.

That being said, I think it's important to maintain the distinction between
the preprocessing and the processing.  In fact, it might be useful to have
an option for outputting a preprocessed file, in case someone needs to see
exactly how their loops are unrolling or something like that.

...Chambers



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.323 / Virus Database: 180 - Release Date: 2/8/2002

Post a reply to this message

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

> If a language has an explicit pre-processing stage, then there is something
> wrong with the language itself. My point is that POV-Ray must not expose
> that to the user -- and hopefully get rid of such internal subdivision as
> well.

I don't think the mere presence of a preprocessor is a flaw in a 
language. And in this case, it is rather unavoidable...unless you want 
to re-evaluate the entire scene for each ray cast.
The POV-Ray control structures (macros, #if-else and #switch 
conditionals, #while loops) are more like preprocessor directives than 
language structures, and this gives them some very useful 
advantages--you can use them to generate scene code automatically, 
making a large number of objects in a union or initializing arrays. 
There isn't a separate pre-parse stage, but the scene parser doesn't see 
the loops and doesn't need to, it just needs to know objects and other 
scene attributes. After parsing, the scene is pretty static, it just 
gets rendered.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

Vadim Sytnikov <syt### [at] rucom> wrote:
> Thorsten, should I reply then that if you fail to see that, then you have
> never had any experience with language design and implementation?

  Aw, come on! All this is sounding like having # characters in script
commands is bad language design.
  Hello? It's just syntax. It could have *anything*. It doesn't have to look
like other languages.
  At least some variants of BASIC use the ':' character as a command separator.
Other languages use ';' as command separator. Some other languages don't use
command separators at all (well, usually whitespace works as separator). In
some languages all commands may be all uppercase, in others they are all
lowercase, and yet in others it doesn't matter how you write them. So what?
It's just syntax. You can't say that one is worse than another.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

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

> You may want to read
> ftp://ftp.ru.com/pub/gamos/povpro/povpro.txt go get a better idea of that.

(I have not read to the end yet, but this is a separate question anyway)
In section 6.2 you mention that the Intel compiler will turn multiple
divisions by the same number into one division and then uses multiplications
for floating-point numbers.  Do you know if in its current version the Intel
compiler still does this?

    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 <3c8f298c$1@news.povray.org> , "Vadim Sytnikov" <syt### [at] rucom>
wrote:

> Thorsten, should I reply then that if you fail to see that, then you have
> never had any experience with language design and implementation? I think
> that I shouldn't -- nor should you use the "arguments" like those you came
> up with...

I fail to see why my arguments are not valid:  As there is no formal language
specification, the only why you can find out that your suggested changes (or
to be more precise the grammar changes they imply) would seriously degrade the
flexibility of POV-Ray.  In the source code you can see that the parsing is
more or less on two separate levels.  One processing directives and the other
layer, below it, processing scene description.  If you actually use the
language as it is for complex tasks, you will find the separation between
scene description and (programming) language very natural and essential for
the flexibility that is simply impossible otherwise.

Further, the conclusion you drew from my argument is incorrect.

    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

On Wed, 13 Mar 2002 20:15:47 +0100, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> you will find the separation between
> scene description and (programming) language very natural and essential for
> the flexibility that is simply impossible otherwise.

It could be compared to the HTML/js pair probably where HTML is document
description and javascript is a substitute of language. AFAIK broswers
parse/render both in one pass.

ABX

Post a reply to this message

> I think many of programing
> languages has some kind of parser directives.

To some degree, yes. Even such a "pure" language as Ada has that -- but only
to control speed vs. space tradeoffs, etc. In fact (although I strongly
dislike Ada...), I think that that is probably the right approach -- to
control parsing, but not alter the contents of source files...

> But that's the case: internall subdivision is required becouse all
#directives
> can appear in any place while scene description parts have clearly
described
> order. As I said I like it. I like tools which represents internal
behaviour
> becouse it gives more control (at least feeling of it).

I like such tools too, but I do not think that POV-Ray directives strictly
fall into this category (more on this later). There is such thing as "the
spirit of C" that current body of ANSI C committee pledged to keep (w/o much
success though :-( ), which means (among other things) and language
statements must be lightweight -- i.e. compiler must not generate heavy code
for simple-looking statements (examples of the opposite are exceptions, RTTI
etc. in C++). All in all, I like transparency in language semantics, too...
but, as we are going to have a chance, would like to improve the way it is
done in POV-Ray.

> Have you any experience how your improvements appear
> nowadays ? I mean are they considered in modern compilers ? Have you
> experimented with them on 3.1 or megapov sources?

No -- I have no clue as to how that works these days. I have switched to
Visual C++, plus I'm using GCC very heavily (a lot of work for ARM and
similar processors). I have not tried Proton for a long time now.

> Perhaps you can share some
> your ideas during beta-testing of 3.5 with two compilators.

That would require access to POV-Ray source code, that I don't have. So I'm
just waiting for the first release.

> I'm still really interested with "what was more elegant in PolyRay"
question.

PolyRay is not THAT ancient, indeed... You may want to get some old release
of Moray, get PolyRay plugin for it, set PolyRay as your current renderer,
and render some sample scene (you cannot just export the scene if your Moray
copy is not registered) -- you should be able to see the difference. As to
what exactly I see as more elegant/appropriate alternative to some pieces of
POV-Ray syntax, I will probably address in another message.

Regards,
Vadim.

Post a reply to this message

"Ben Chambers" <bdc### [at] yahoocom> wrote>
> The explicitness of a preprocessing stage has nothing to do with the
> language itself.  For instance, MSVC will automatically, preprocess,
compile
> and link objects all in one step.  gcc on the other hand, has separate
tools
> for preprocessing, compiling, assembling, and linking (though you have a
> common 'control' file to do it all at once).  In one of them, it is very
> explicit; in the other, it is implicit.  But they both work.

Exactly. I would add that, long ago, there was such a thing as Zortec C
compiler (that product was first named Datalight Optimum C, then Zortec
C/C++, then Symantec C/C++; highly regarded; written by Walter Bright) that
had separate parsing (parse tree generation), optimization, and code
generation stages; with intermediate files, of course :-) But does that
prove anything?

I do think that if a language *defines* distinct pre-processing stage, that
*unnecessary* limits it, to a great extent (more on this in another
message). In C, many things could have been rectified if 'const' were
defined properly (not as a mere storage class specifier, but in a way it was
done in C++), and 'inline' were timely introduced in standard (and not
merely provided as extensions by vistually every compiler vendor).

> That being said, I think it's important to maintain the distinction
between
> the preprocessing and the processing.  In fact, it might be useful to have
> an option for outputting a preprocessed file, in case someone needs to see
> exactly how their loops are unrolling or something like that.

I do not think this would be useful at all... How often do you look at the
output of C preprocessor? As to me, I have a definit answer: about a dozen
times -- when I was tweaking Decus CPP (freeware C preprocessor) to my needs
:-)

Post a reply to this message

"Christopher James Huff" <chr### [at] maccom> wrote
> I don't think the mere presence of a preprocessor is a flaw in a
> language. And in this case, it is rather unavoidable...unless you want
> to re-evaluate the entire scene for each ray cast.

Using functions instead of some macros is effectively the replacement of
preprocessor features with the language features. Does this lead to
re-evaluation of entire scene for each ray cast?

Of course, some things must be 'const'... But even this requirement can be
lifted if an object is to be used solely in the 'object' pattern, right?

Post a reply to this message

On Thu, 14 Mar 2002 12:39:35 +0300, "Vadim Sytnikov" <syt### [at] rucom> wrote:
> Using functions instead of some macros is effectively the replacement of
> preprocessor features with the language features. Does this lead to
> re-evaluation of entire scene for each ray cast?

Using functions() in parsing time is the same as using trace() for further
parsing.

ABX

Post a reply to this message