 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rafal 'Raf256' Maj <raf### [at] raf256 com> wrote:
> 20 + $x will result in 120 (x is used like number)
FYI it didn't work that way in MegaPov.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote in news:3db1cf8f@news.povray.org
> Rafal 'Raf256' Maj <raf### [at] raf256com> wrote:
>> 20 + $x will result in 120 (x is used like number)
> FYI it didn't work that way in MegaPov.
Yes - it didn't. Do You think it would be a good idea to allow such
behaviour ?
--
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote in message
news:Xns### [at] 204213191226...
> syntax $var_name ihas one greate advantage :
>
> $sphere = 10;
> $ior = 50;
>
> You can use variable names that are reserved words. This is in fact VERY
> usefull, in stuff like :
That's not useful, in fact it sounds like a terrible idea, and isn't any
more possible with that syntax anyway.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote in message
news:Xns### [at] 204213191226...
> I.e someone will write script, with variables like say :
> a, b, c, speed, displacment, size
> It will work fine, until in say POV 4.0 displacment will became a
> reserved word and stop this script from working.
Use upper case in your variable names. Upper case words will never be
reserved.
> What do You think about allowing, as PHP, syntax with variant types,
> say :
> $x = 100;
> "foo"+$x+"bar" will result in "foo100bar" (x is used like string)
> and :
> 20 + $x will result in 120 (x is used like number)
You're joking, right? You *like* that?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christopher James Huff" <cja### [at] earthlinknet> wrote in message
news:3db1f4a3@news.povray.org...
> "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote in message
> news:Xns### [at] 204213191226...
> > I.e someone will write script, with variables like say :
> > a, b, c, speed, displacment, size
>
> Use upper case in your variable names. Upper case words will never be
> reserved.
Would it be conceivable that a future POV-Ray could tag any and all
user-defined identifiers, regardless of case, as a non-keyword? It's not
always compulsory to use upper case letters so it can seem okay. In fact,
people have often complained they couldn't use a number as the first
character either.
> > What do You think about allowing, as PHP, syntax with variant types,
> > say :
> > $x = 100;
> > "foo"+$x+"bar" will result in "foo100bar" (x is used like string)
> > and :
> > 20 + $x will result in 120 (x is used like number)
>
> You're joking, right? You *like* that?
That would be weird to me.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"hughes, b." <omn### [at] charternet> wrote in
news:3db1fdaf$1@news.povray.org
>> Use upper case in your variable names. Upper case words will never be
>> reserved.
Ok - i didn't knew that. Maybe it should be putted in manual and FAQ ?
>> > "foo"+$x+"bar" will result in "foo100bar" (x is used like string)
>> > 20 + $x will result in 120 (x is used like number)
>> You're joking, right? You *like* that?
> That would be weird to me.
PHP users are glad with that :P but it was just a sugestion.
--
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote in message
news:Xns### [at] 204213191226...
> "hughes, b." <omn### [at] charternet> wrote in
> news:3db1fdaf$1@news.povray.org
>
> >> Use upper case in your variable names. Upper case words will never be
> >> reserved.
>
> Ok - i didn't knew that. Maybe it should be putted in manual and FAQ ?
Section 6.1.1 in manual.
--
Robert Chaffe
http://www.donovansweb.com/~chaffe/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"hughes, b." <omn### [at] charternet> wrote in message
news:3db1fdaf$1@news.povray.org...
> Would it be conceivable that a future POV-Ray could tag any and all
> user-defined identifiers, regardless of case, as a non-keyword? It's not
> always compulsory to use upper case letters so it can seem okay. In fact,
> people have often complained they couldn't use a number as the first
> character either.
There are two reasons not to allow keywords as identifiers:
1: Ambiguity. In some cases, it could be impossible or difficult for the
parser to tell a keyword from an identifier of the same name. For example:
def while = 0;
while(while < 10)
{
while++;
}
Most parsers will try to start another while loop nested in the first one.
Catching this case complicates the parser while adding no functionality.
Another example:
function while(fooBar) {...do something...}
while(1);
Now, write a parser that handles *that* properly. There is no way to tell
the difference between a function call and an infinite loop unless you
change the loop syntax.
You could add a mandatory first character, like "$", but that doesn't solve
anything...it makes things less readable by scattering meaningless symbols
everywhere, and makes every name longer by one useless character.
If you really want variables like this so you can use keywords as names,
just put a "_" in front of the names, like "_while" or "_declare". Does the
same thing, without annoying everyone else. Just don't ask anyone else to
put up with your code...
2: Readability. It is far better if the word used for a keyword is *always*
used for a keyword.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rafal 'Raf256' Maj <raf### [at] raf256com> wrote:
> Yes - it didn't. Do You think it would be a good idea to allow such
> behaviour ?
IMHO, no. I like "a+b" a lot more than "$a+$b".
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christopher James Huff" <chr### [at] maccom> wrote in message
news:chr### [at] netplexaussieorg...
>
> def myCounter = 0;
> while(myCounter < 10) {
> myCounter += 1;
> }
>
<shudders>
I "mastered" programming in high school and college learning BASIC and some
FORTRAN.
I am too stupid to figure out C.
Please don't make the SDL just a bastardized C. Don't make it eclectic. As
klunky as it is, the current SDL is intuitive.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
