POV-Ray : Newsgroups : povray.pov4.discussion.general : Random POV-Ray 4 SDL proposal, #2 : Re: Random POV-Ray 4 SDL proposal, #2 Server Time
26 Sep 2021 05:26:36 EDT (-0400)
  Re: Random POV-Ray 4 SDL proposal, #2  
From: William F Pokorny
Date: 14 Dec 2015 07:54:14
Message: <566ebbf6$1@news.povray.org>
On 12/13/2015 04:54 PM, clipka wrote:
> Here's another one.
>

Thanks for the earlier response on my comments on #1 - got it I think.

Disclaimer. I'm a hack programmer, not a professional one. While I am 
offering opinions, keep in mind I might not know what I'm talking about. 
Offering that up because to me your proposal below feels OK to me too. 
Thinking a statements approach might be somewhat simpler initially for 
users new to SDL.

Is it an aim for the new inbuilt SDL to be a language easier for those 
with no programming experience to use?

I see the primary aim as cleaning up the SDL internal and external to 
POV-RAY for current use and extension. I tripped again the other day 
trying:

#declare WarpSevenScotty = warp {...}
...
     warp { WarpSevenScotty }
...
     warp { WarpSevenScotty }

which I believe should work if behavior was consistent in the current 
SDL, but it doesn't. A reused macro with the common warp is my work 
around.

> This time I start out entirely differently: This language isn't based on
> description of hierarchical data, salted with control statements.
>
> This time statements are the one and only thing: A scene file is a list
> of statements.
>
> For the sake of preventing ambiguities, and for the sake of consistency,
> all statements are terminated by a semicolon unless noted otherwise.
>
> For the sake of continuity, I'll use "#" as first characters of my
> control statements again, and for the sake of simplicity I'll stick to
> the few ones defined in the last proposal:
>
>    #if (CONDITION)
>      STATEMENT ;
>    #elif (CONDITION)
>      STATEMENT ;
>    #else
>      STATEMENT ;
>
>    #loop (IDENTIFIER)
>      STATEMENT ;
>
>    #break (IDENTIFIER) ;
>
>    #continue (IDENTIFIER) ;

Is the IDENTIFIER the loop variable and optional ?

>
> A statement may be a block:
>
>    {
>      STATEMENT ;
>      STATEMENT ;
>      STATEMENT ;
>    }
>
> A statement block is the only statement /not/ terminated by a semicolon.
>
> A statement may be an assignment:
>
>    IDENTIFIER = EXPRESSION ;
>
> An expression may be a scene element, such as a geometric primitive, a
> texture or the like. Such an expression is comprised of a /type/
> identifier and a statement block.
>
>    sphere { ... }
>    texture { ... }
>
> A statement may also be a sole expression; in this case, the result is
> "dropped into" the block it resides in, as a /child/ of the block:
>
>    foo = box { ... }
>    union
>    {
>      sphere { ... }
>      sphere { ... }
>      box { ... }
>      foo ;
>      ...
>    }
>
> Note how, in contrast to the current SDL, the object expression isn't
> wrapped into "object { ... }".

Simpler for direct use, but supposing it could be wrapped in object { } 
if we say wanted to translate it inside the union ?

>
> Besides child elements, scene elements also have properties. The
> following statement sets a property of the current block:
>
>    IDENTIFIER: EXPRESSION ;
>
> All object properties are set via identifier, rather than anonymlously
> by position; for instance, instead of
>
>    sphere { CENTER, RADIUS }
>
> it will be:
>
>    sphere {
>      center: EXPRESSION ;
>      radius: EXPRESSION ;
>    }
>

I personally like this form though more verbose. Any syntax more 
explicit about what property is being set is much clearer to new users 
especially - expect many periodic users too.

Perhaps it is just my long term memory is less capable than others, but 
after being away from POV-Ray for a time I always find myself again 
looking up syntax for things. Why my own SDL generating code tends to 
look like:

DefSphere MySphere -center <0,0,0> -radius 1.0

>
> Well, that's about as far as I've thougt this through for now.
>


Post a reply to this message

Copyright 2003-2021 Persistence of Vision Raytracer Pty. Ltd.