"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.

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 completely agree with those who say that POV-Ray has marvelous
community, which actually represent part of the joy for those using
POV-Ray -- let's keep good spirit, OK?

As to my POV-Ray background... well, I made the first custom version of
POV-Ray back in 1996, and made it publicly available in 1997. It was
available at the CompuServe's GO POVRAY forum, library section 17; it is
still available at ftp://ftp.ru.com/pub/gamos/povpro/. Since then, I've made
several more versions, mostly dealing with animation, for my personal use.
BTW, one of the features added to the public version was the ability to
examine internal representation of scenes, since that (coupled with overall
language structure) was always of interest to me... You may want to read
ftp://ftp.ru.com/pub/gamos/povpro/povpro.txt go get a better idea of that.

Of course, my input into the official POV-Ray development is not only
incomparable, but is neglectable compared to yours. I would like to assure
you that I really think so -- I am aware of what you are responsible for.
All I did for the *official* POV-Ray is fixed two bugs in compressed BMP
reader, improved portability of the utility word/dword reading routines,
proposed portability enhancements to the Targa reading code... plus probably
sparkled interest in Intel's Proton compiler -- the thing is that I used its
preview version, issued by Intel at one of their seminars, and that
contributed significantly to the overall performance.

So, at large, my proposal is this -- lets respect each other and exchange
real arguments. I would be happy to discuss everything with you, or anybody
else, then.

Regads,
Vadim.

Post a reply to this message

On Wed, 13 Mar 2002 13:27:23 +0300, "Vadim Sytnikov" <syt### [at] rucom> wrote:
> "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.

I think there is not so much SDLs to compare but I think many of programing
languages has some kind of parser directives. My native platform is 4GL by
Progress and there are preprocesor directives. They all start with &
character. I don't think that they looked to POV-Ray becouse POV-Ray is older.
I don't think POV-Team looked at Progress either. Perhaps there is general
rule for preprocesors.

> My point is that POV-Ray must not expose that to the user
> and hopefully get rid of such internal subdivision as well.

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).

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

Very interesting reading. 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 ? Perhaps you can share some
your ideas during beta-testing of 3.5 with two compilators.

> I would be happy to discuss everything with you, or anybody
> else, then.

I'm still really interested with "what was more elegant in PolyRay" question.
For example could you "translate" one sample source from current 3.5 package
with various scene components and directives if possible (of course excluding
not portable things)?

ABX

Post a reply to this message

On Wed, 13 Mar 2002 12:42:24 +0100, W�odzimierz ABX Skiba <abx### [at] babilonorg>
wrote:
> I don't think that they looked to POV-Ray becouse POV-Ray is older.

Of course younger than Progress.

ABX

Post a reply to this message

"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

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

I don't know -- I did not use Intel compiler for several years now. What I
do know is that neither Visual C 6.0 nor GCC 2.95 (the compilers I'm
currently using) can do this...

Post a reply to this message

> 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.

Ironically, what I'm talking about is that same flexibility... Say, what
about using loops and switches in functions? Although I did not see the code
yet, I can only guess why, but pretty reliably -- based on the fact that you
used select() instead of simple 'arithmetic if'...

I'm sure that one day we will see functions as complex as shaders in
RenderMan. By the way, I do not think that there exist any fundamental
difficulty for that -- I know that many have branded that not feasible on
portability grounds. But -- that only applies to the solution that was
implemented in POVMan (based on POV-Ray 2.2, IIRC), which employed bytecode
compiler built with Flex/Bison. If you look at how it was done in BMRT, you
will find quite different solution, less powerful, but more portable (SL
files are not even compiled, they are, err... preprocessed :-)

So my point is -- we should not have, say, two different if's, for parse and
rendering time, but rather a single statement. If its control expression
does evaluate to a constant -- OK, it works like present #if. If it does
not -- well, it depends. If context does allow the use of functions (say, in
a height_field or an image_map), then, if we are not inside a function body
already, then that 'if' should be implicitly wrapped by the automatically
generated function (and should thus work as 'if' in Algol -- that is, return
a value). If the context does not allow that -- signal an error.

These may probably be tomorrow's solutions, but we must not render them
theoretically impossible today...

Post a reply to this message

Vadim Sytnikov wrote:
> 
> [...]
> 
> I'm sure that one day we will see functions as complex as shaders in
> RenderMan. By the way, I do not think that there exist any fundamental
> difficulty for that -- I know that many have branded that not feasible on
> portability grounds. But -- that only applies to the solution that was
> implemented in POVMan (based on POV-Ray 2.2, IIRC), which employed bytecode
> compiler built with Flex/Bison. If you look at how it was done in BMRT, you
> will find quite different solution, less powerful, but more portable (SL
> files are not even compiled, they are, err... preprocessed :-)

One major concern about functions is speed.  Although PovMan can be very
useful, the performance of shaders compared to Povray 3.5 functions is
rather bad i think.  I have not worked with BMRT, but i doubt it is
faster.

> So my point is -- we should not have, say, two different if's, for parse and
> rendering time, but rather a single statement. If its control expression
> does evaluate to a constant -- OK, it works like present #if. If it does
> not -- well, it depends. If context does allow the use of functions (say, in
> a height_field or an image_map), then, if we are not inside a function body
> already, then that 'if' should be implicitly wrapped by the automatically
> generated function (and should thus work as 'if' in Algol -- that is, return
> a value). If the context does not allow that -- signal an error.

From how i understand this you want to mix up the parse time and render
time level.  Note this is quite different from the previosly discussed
directives and scene description layers during parsing.  I don't know how
much you have worked with Povray 3.5 functions, but to distinguish between
those two levels is quite essential for scene design.

For example have a look at:
http://www-public.tu-bs.de:8080/~y0013390/pov/water/water_inc.html

for a scene efficiently using directives in functions.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 13 Mar. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

On Thu, 14 Mar 2002 15:06:32 +0300, "Vadim Sytnikov" <syt### [at] rucom> wrote:
> Ironically, what I'm talking about is that same flexibility... 

All thigs you described lead you to reevaluation for every ray. "#If"
statement is used to return part of code at time of calling this "#if".
"select" statement is used to return float at time of calling this "select".
If we join them then for every call it should be reevaluated. Imagine such
example:

pigment{
  function{
    if(y>0)
     pattern{object{
       if(z>0)
         sphere{0 1
       else
         box{-1 1
       end
         rotate x* if ( vlength(<x,y,z> > 1 )  30 else (2+x+y+z) end
       }}}
    else
      x+y+z
   end
  }
}

Of course everybody wants local variables in functions and more programing
features in functions but creation of function should be separated with runing
it. Note you could use loop: to create short function with loop started for
each call, or long function with loop started by preprocesor and called
unrolled but efficient. How can parser know what you want if you don't specify
this with different name for each loop keyword ?

ABX

Post a reply to this message

"W³odzimierz ABX Skiba" <abx### [at] babilonorg> wrote
> If we join them then for every call it should be reevaluated. Imagine such
> example:
>
> pigment{
>   function{
>     if(y>0)
>      pattern{object{
>        if(z>0)
>          sphere{0 1
>        else
>          box{-1 1
>        end
>          rotate x* if ( vlength(<x,y,z> > 1 )  30 else (2+x+y+z) end
>        }}}
>     else
>       x+y+z
>    end
>   }
> }

Thanks a lot -- you have given me a perfect illustration why (in a good
language) there must be no such thing as pre-processor. Let's rip short
piece out of it and have a closer look:

object{
   if(z>0)
     sphere{0 1
   else
     box{-1 1
    end
    rotate x* if ( vlength(<x,y,z> > 1 )  30 else (2+x+y+z) end
}

This code fragment is only possible since it is fed to pre-processor, not to
SDL interpreter... Otherwise, you would *have* to write something like this:

#local Rotate = transform { rotate ... }
object { ... Rotate }

(for obvious reasons), that is both more reliable, and... more elegant. A
language with that powerful pre-processor is at risk to quickly become a
"write-only" language, you know... (Perl had succeeded at that w/o
preprocessor at all, but nevertheless... :-)

Post a reply to this message

On Thu, 14 Mar 2002 17:12:26 +0300, "Vadim Sytnikov" <syt### [at] rucom> wrote:
> Thanks a lot -- you have given me a perfect illustration why (in a good
> language) there must be no such thing as pre-processor. 

I think you missed important part of this example, it is written inside of
function so this means it should be evaluated for every intersection point as
showed used x,y,z variables.

> This code fragment is only possible since it is fed to pre-processor, not to
> SDL interpreter... Otherwise, you would *have* to write something like this:
>
> #local Rotate = transform { rotate ... }
> object { ... Rotate }

I don't understand your answer at all. And I feel that it is becouse you don't
understand existence of function{}. (Note above two-line-script contains
error)

> (for obvious reasons), that is both more reliable, and... more elegant.

It is elegant separating "if"s with different behaviour IMO

ABX

Post a reply to this message

Vadim Sytnikov wrote:
> I'm sure that one day we will see functions as complex as shaders in
> RenderMan. By the way, I do not think that there exist any fundamental
> difficulty for that -- I know that many have branded that not feasible on
> portability grounds. But -- that only applies to the solution that was
> implemented in POVMan (based on POV-Ray 2.2, IIRC), which employed bytecode
> compiler built with Flex/Bison. If you look at how it was done in BMRT, you
> will find quite different solution, less powerful, but more portable (SL
> files are not even compiled, they are, err... preprocessed :-)
> 
POVMan's SL compiler output should be quite portable: bytecode is 
written as text byte-by-byte and there shouldn't be problems with endian 
  or word length.
To me BMRT's SL compiler output reminds more assembly language, than 
preprocessed statements. And POVMan's SLC is capable of similar output, 
only problem is that POVMan itself can't read this output (for this 'SL 
assembly' parsing should be implemented, but bytecode reading is much 
more easier).
One problem with using SL from POV is its complexity: one should deal 
with multiple files, compile them, learn new language etc. Additionally 
there could be legal considerations as well.

Post a reply to this message

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

>> 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?
>
> I don't know -- I did not use Intel compiler for several years now. What I
> do know is that neither Visual C 6.0 nor GCC 2.95 (the compilers I'm
> currently using) can do this...

Which is a good thing because this change is an "illegal optimization", or
less friendly formulated a serious flaw in the compiler - at no point may a
compiler alter the result of a computation.  If it does alter the result of a
computation it has to be considered a bug.  Looks like whoever implemented
this didn't read the various articles and book chapters about floating-point
optimizations that are 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

> > #local Rotate = transform { rotate ... }
> > object { ... Rotate }
>
> I don't understand your answer at all.

Sorry, I was probably unclear -- in that I have omitten several steps that
seemed obvious to me... I'll try once again. Here is your code with my
marks:

  if(z>0)
     sphere{0 1
                 ^-------- (A)
  else
     box{-1 1
           ^--------------(B)
  end
     rotate x* if ( vlength(<x,y,z> > 1 )  30 else (2+x+y+z) end
   } <-------------------(C)

If 'if' statement were a real statement, and not merely a pre-processor
directive, then you would be unable to place parentheses like that (marks
(A) and (B)). Such placement is always considered dangerous -- you are
subdividing statement into pieces, AND pre-processor is unable to help you
to find any bugs, since it has no notion of what is between its
directives... Even if you have exceptional abilities and can maintain such a
code, other readers of your code may easily get confused with such grouping
(well, not with *that* example, but with a bit more complex...) That is why
such (once again, not this, but a more complicated code written in the same
manner) is often called a "write-only" code.

You are not to blame for that -- since 'if', 'switch' etc. keywords are
pre-processor directives rather than true language statements (that obey
some syntax rules), you are almost encoraged to write like that.

Now the part that confused you... In a well-designed language, you may
almost always gain good performance, but -- without hacks. I tried to draw
an example... To me, it was obvious that what you tried to do (with if-end
block containing marks (A) and (B)) was to supply a single transform to
variable shape definition -- so I just tried to illustrate that, if you were
dealing with an interpreter, and not mere pre-processor, you would be
*forced* to define transformation and then re-use that in several object
definitions. The interpreter would *not* allow you break pairs of
parentheses like that. And guess what? I think that that would be right!

Post a reply to this message

> at no point may a
> compiler alter the result of a computation.  If it does alter the result
of a
> computation it has to be considered a bug.

For the Intel compiler, that would only be true if intermediate result (of
the division of 1 by common divisor) would be stored in a 64-bit (double)
temporary variable. If it is kept in an fp register (80 bits), or in a 'long
double' temporary variable, then accuracy of the result would still be
*above* required by IEEE 754. Unfortunately, I can't remember whether that
(maintaining 80-bit accuracy across computations) was the case, but I
believe so...

Post a reply to this message

"Vadim Sytnikov" <syt### [at] rucom> schrieb im Newsbeitrag
news:3c90feae@news.povray.org...
> > > #local Rotate = transform { rotate ... }
> > > object { ... Rotate }
> >
> > I don't understand your answer at all.
>
> Sorry, I was probably unclear -- in that I have omitten several steps that
> seemed obvious to me... I'll try once again. Here is your code with my
> marks:
>
>   if(z>0)
>      sphere{0 1
>                  ^-------- (A)
>   else
>      box{-1 1
>            ^--------------(B)
>   end
>      rotate x* if ( vlength(<x,y,z> > 1 )  30 else (2+x+y+z) end
>    } <-------------------(C)
>
> If 'if' statement were a real statement, and not merely a pre-processor
> directive, then you would be unable to place parentheses like that (marks
> (A) and (B)). Such placement is always considered dangerous -- you are
> subdividing statement into pieces, AND pre-processor is unable to help you
> to find any bugs, since it has no notion of what is between its
> directives... Even if you have exceptional abilities and can maintain such
a
> code, other readers of your code may easily get confused with such
grouping
> (well, not with *that* example, but with a bit more complex...) That is
why
> such (once again, not this, but a more complicated code written in the
same
> manner) is often called a "write-only" code.
>
> You are not to blame for that -- since 'if', 'switch' etc. keywords are
> pre-processor directives rather than true language statements (that obey
> some syntax rules), you are almost encoraged to write like that.

I am sorry, but I am unable to follow you.  Given the example he gave is not
pre-processes but would be allowed by the language, where exactly would be
the problem?  The example is fictional and thus there cannot be the problem
you describe, at least assuming I understood what problem you are talking
about...

    Thorsten

Post a reply to this message

On Fri, 15 Mar 2002 10:55:25 +0100, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> The example is fictional

That's it. I've connected keyword and features of "if" with "select"
application as he suggested (or at least as I understand his suggestions). And
it clearly showed how it can confuse. Loosing features of current "if"
(spliitting closed statements) could be of course possible but completly
useless imo. Directives _with features_ state power of L in SDL whatever
syntax they have.

And btw Thorsten, thanks for "select" extraction. It helped me a lot in my
current #switch work :-)

ABX

Post a reply to this message

> Given the example he gave is not
> pre-processes but would be allowed by the language, where exactly would be
> the problem?

The example that ABX gave us would *not* work in a language that has normal
scope rules (which even BASIC and Fortran have these days -- to some
extent). Below, left (opening) parenthesis opens scope for the 'sphere'
statement. If the 'if' and 'else' keywords were true language statements,
and not merely pre-processor directives, then it would be necessary to have
a right (closing) parenthesis before the 'else' statement.

>   if(z>0)
>      sphere{0 1
>                ^-------- (A)
>   else

That is, if we had a consistent language, the example should have looked
like this (extra parentheses added to just make scopes more clear; I do not
insist language syntax should necessarily require that):

if( z>0) {
  sphere {
    // sphere definition goes here
  }
} else {
  // another shape definition
}

In other words, the 'sphere' scope should have been closed before the 'else'
keyword. Therefore, transform definition should have been specified before
the 'else' keyword as well. Therefore, the only way to avoid duplicating
transform definition would be to declare it beforehand, and then reference
from within sphere definition, etc. (as I wrote earlier).

Post a reply to this message

Vadim Sytnikov wrote:

>   if(z>0)
>      sphere{0 1
>                  ^-------- (A)
>   else
>      box{-1 1
>            ^--------------(B)
>   end
>      rotate x* if ( vlength(<x,y,z> > 1 )  30 else (2+x+y+z) end
>    } <-------------------(C)

If you want something different from:

union {
 intersection {
   sphere { 0,1 }
   plane { -z,0}
   }
 intersection {
  box {-1,1}
  plane { z,0}
 }
 rotate ....
}

then you are doomed to work with mesh or rewrite the whole pov-engine.
Especially if you absolutlely want the non-linear transform from the second if.
Then you could make your own SDL, without preprocessor visible level if you wish.

-- 
Non Sine Numine
http://grimbert.cjb.net/
Puis, s'il advient d'un peu triompher, par hasard,
Ne pas être obligé d'en rien rendre à César,
Vis-à-vis de soi-même en garder le mérite,
Bref, dédaignant d'être le lierre parasite,
Lors même qu'on n'est pas le chêne ou le tilleul,
Ne pas monter bien haut, peut-être, mais tout seul !

Post a reply to this message

On Fri, 15 Mar 2002 18:12:46 +0300, "Vadim Sytnikov" <syt### [at] rucom> wrote:
> The example that ABX gave us would *not* work in a language that has normal
> scope rules (which even BASIC and Fortran have these days -- to some
> extent).

But POV-SDL isn't normal language. It's mix of language and description so it
don't have to have "normal" _language_ scope rules. Again going back to
HTML/script example. Did you use php ? You can open HTML tag inside php
condition statement and close it outside. Something like:
    <?php if (a>3) { ?>
      <p align="left" style="color:#123456">
    <?php } else { ?>
      <p align="right">
    <?php } ?>
      important text
    </p>
is valid and php works like preprocesor for webserver. There are probably some
leyers in processing but they are invisible for both: surfer and designer. The
same is valid for other server-side scripts. So POV-SDL works typically for
such combinations - just  all-in-one.

ABX

Post a reply to this message

On Thu, 14 Mar 2002 22:50:01 +0300, "Vadim Sytnikov" <syt### [at] rucom> wrote:
> The interpreter would *not* allow you break pairs of
> parentheses like that. And guess what? I think that that would be right!

BTW: I think You will not convince me but I can't say You are or are not right
at all. Mainly becouse my opinion is subjective - I like power which appear in
ability to write short scripts like for example sigs :-)

ABX

Post a reply to this message

"W³odzimierz ABX Skiba" <abx### [at] babilonorg> wrote
> But POV-SDL isn't normal language. It's mix of language and description so
it
> don't have to have "normal" _language_ scope rules.

You have to have well-defined scope rules to just cope with the complexity.
To make your scenes editable by someone else -- that is, to share code
(models etc.) Have you been using someone else's POV-Ray model recently?
Were you able to edit it?

> Did you use php ? You can open HTML tag inside php
> condition statement and close it outside.

Have you been editing someone else's php code recently? Were that easy?

I'm not talking about what is possible (has precedents etc.) and what isn't.
I'm talking about what's better (== easier, more reliable).

Post a reply to this message

"W³odzimierz ABX Skiba" <abx### [at] babilonorg> wrote
> I like power which appear in
> ability to write short scripts like for example sigs :-)

I see... and I would like to assure you that I... err, share your desire for
poerful features. The *only* question is -- how is that power unleashed?

I, for one, cannot be convinced not to use forward goto's in C at all --
there is simply no other efficient way to escape deeply nested loop. In
Java, one can demand that there must be no goto's at all -- since there are
labeled loops AND you can always 'break' the loop you want (by its label).
In C, you sometimes have no alternative, especially in a time-critical
code...

So, as to POV-Ray, the challenge is just provide powerful AND
well-structured featureas which will render puwerful BUT unreliable features
obsolete.

Post a reply to this message

On Fri, 15 Mar 2002 19:39:04 +0300, "Vadim Sytnikov" <syt### [at] rucom> wrote:
> You have to have well-defined scope rules to just cope with the complexity.
> To make your scenes editable by someone else -- that is, to share code
> (models etc.) Have you been using someone else's POV-Ray model recently?
> Were you able to edit it?

Well, You can look at povray.general, povray.text.scene-files and
povray.binaries.scene-files into splitted thread about IsoCSG include file. It
started yesterday and I have posted at least 4 extensions into that (including
whole rebuild with different parameters handling) and discuted it even more.
But IIRC there wasn't such splitted syntax. But I always look into sigs of
POV-ers. They _always_ use confusable (is there such word?) syntax. Usually it
takes me some short time to understand - but those sigs were written to
confuse so nothing strange. Anyway if there (in sigs) is something to improve
in confusing or length I usually send it. It's known fact, you can dig on
news.

> > Did you use php ? You can open HTML tag inside php
> > condition statement and close it outside.
>
> Have you been editing someone else's php code recently? Were that easy?

I haven't used php recently so I can't answer. I'm also not even half
experienced in php as in pov (supposing I have some experience in POV) so I'm
probably not a good target for this question. But I use other server-side
language (WebSpeed platform) and work in team with success. We builded and
maintain broker service with it. It use html splitting as in posted example.

> I'm not talking about what is possible (has precedents etc.) and what isn't.
> I'm talking about what's better (== easier, more reliable).

Allocating memory for additional objects, floats, strings, transformations
isn't better in this case imo.

ABX

Post a reply to this message

> They _always_ use confusable (is there such word?) syntax.

Obfuscated is the right word. There is/was even such thing as IOCCC (stands
for the International Obfuscated C Code Contest); IMHO quite amusing...

Post a reply to this message