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