In article <Xns### [at] netplexaussieorg> , ingo 
<ing### [at] tagpovrayorg>  wrote:

> Why not throw the # away completely?

Because then you could no longer distinguish parse-time processing from
render-time processing, which would close the door for many possible future
features.  And it would make parsing infinitly more complex (from a runtime
complexity perspective).

    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 news:3ff6c719$1@news.povray.org Thorsten Froehlich wrote:

> Because then you could no longer distinguish parse-time processing from
> render-time processing, [...]

I do not understand, probably because I don't know what both are. 
Parse-time processing, I guess, is all the stuff that has to done to get 
the objects into memory. That would include doing the loops and macro's 
and stuff.
Render-time processing, besides of shooting the rays I can only think of 
functions.


Ingo

Post a reply to this message

In article <Xns### [at] netplexaussieorg> , ingo 
<ing### [at] tagpovrayorg>  wrote:

> I do not understand, probably because I don't know what both are.

It is much like the difference between functions and declares.

    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 wrote:
> 
>>Why not throw the # away completely?
> 
> Because then you could no longer distinguish parse-time processing from
> render-time processing, which would close the door for many possible future
> features.  And it would make parsing infinitly more complex (from a runtime
> complexity perspective).

Not to mention the extreme obfuscation possible:

sphere {
   J J = J + K = 1 - J; 1; K
}

The version you suggested is only slightly better:

sphere {
   J #J = J + #K = 1 - J; 1; K
}

I'd really suggest to have a keyword (like #set) for this purpose.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 25 Oct. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

In article <3ff63f78@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

> > #declare, #local: obsolete, deprecated, but unchanged in operation for 
> > backwards compatibility.
> > #global, #def or #define, #set: as described above, with #def declaring 
> > a local variable.
> 
>   How would #def be different from #local?

It would give a warning or error when used on an existing variable.


>   What's wrong with #local? It's certainly a whole lot more descriptive
> than #def.

And it's used. Changing it would break backwards compatibility.


>   I think that a lot of the confusion-causing problems in the current
> macro syntax would be avoided if you could specify if the macro takes
> its parameter by value (which would be the default in the current syntax)
> or by reference (with a special symbol or keyword).

I don't like this idea. One thing about C++ that I've never liked was 
the way you couldn't tell by reading the call whether you were passing 
by reference or by value. If something like this were added, I would 
prefer an explicit reference, something closer in usage (though not 
syntax) to pointers.

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

In article <Xns### [at] netplexaussieorg>,
 ingo <ing### [at] tagpovrayorg> wrote:

> >>     #J = J + 1;
> > I like this syntax for manipulating already declared variables.
> 
> Why not throw the # away completely?
> 
> J = 0;
> J = J + 1;
> 
> Everything is local, unless it is declared global,
> 
> #global J = "global"

Ew. There's no way of telling a declaration apart from an assignment, 
unless it's global. You just completely broke the main benefits of my 
suggested method. Look at this code:

J = 0;
#while(J < 10)
    j = J + 1;
#end

That's an infinite loop. This isn't, it's an error:
#def J = 0;
#while(J < 10)
    #j = J + 1;
#end

This would also be harder to parse, and would break consistency with the 
rest of the language. I'd actually prefer something like this:

def J = 0;
while(J < 10) {
    J = J + 1;
}

or at least:

def J = 0;
while(J < 10)
    J = J + 1;
end

But you'd have to redesign the language and completely redo the parser. 
What I suggested only requires 3 small additions.

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

In article <3ff4a58c$1@news.povray.org>,
 Florian Brucker <tor### [at] torfboldcom> wrote:

> >   But the current behaviour can be useful sometimes.
> Do you mind to give an example?

The Extents() and Isect() macros, which return multiple values through 
their parameters.


> > If you make a #local in an include file, its scope will be only inside
> > that file.
> But you can't use it properly in macros:

You're talking about an entirely different kind of scope here. It would 
be useful in some cases, but I think what you want would be done better 
with object-oriented programming structures.

-- 
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 <cja### [at] earthlinknet> wrote:
> >   How would #def be different from #local?

> It would give a warning or error when used on an existing variable.

  Wasn't #set for that? I'm confused.

> >   What's wrong with #local? It's certainly a whole lot more descriptive
> > than #def.

> And it's used. Changing it would break backwards compatibility.

  I don't understand what you are saying.

> I don't like this idea. One thing about C++ that I've never liked was 
> the way you couldn't tell by reading the call whether you were passing 
> by reference or by value.

  Currently you have only one option: By reference. And this is causing
confusion.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

In article <3ff750b5@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

> > It would give a warning or error when used on an existing variable.
> 
>   Wasn't #set for that? I'm confused.

#set or #IDENTIFIER would prevent you from accidentally defining a new 
variable...it would give an error if you tried to modify a nonexistent 
variable.
#def would prevent you from accidentally redefining an existing 
variable. It would give an error or warning if the new variable would 
replace the existing one.


> > >   What's wrong with #local? It's certainly a whole lot more descriptive
> > > than #def.
> > And it's used. Changing it would break backwards compatibility.
>   I don't understand what you are saying.

Well, the warning wouldn't break backwards compatibility, but would slow 
down the parsing of any old scene and drown out more legitimate 
warnings. The error would break any old scene. Or maybe it could be made 
to depend on the version directive...


> > I don't like this idea. One thing about C++ that I've never liked was 
> > the way you couldn't tell by reading the call whether you were passing 
> > by reference or by value.
> 
>   Currently you have only one option: By reference. And this is causing
> confusion.

Not really. It surprised someone, but it's certainly not a common source 
of confusion, and it only happens when someone's doing something a 
little strange anyway (modifying a parameter). It's easy to write the 
macro to work with a local version, and that's what should be done if it 
isn't returning something through the parameter.

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

in news:cja### [at] netplexaussieorg Christopher 
James Huff wrote:

> You just completely broke the main benefits of my 
> suggested method.

Sorry Chris,

I more or less jumped in the middle of the thread by somehowe missing the 
middle section of it. I'll try to pay more attention ... ;)


Ingo

Post a reply to this message