"Mr" <nomail@nomail> wrote:
> clipka <ano### [at] anonymousorg> wrote:

> > A simple POV-Ray scene described in this format might look like this:
> [...]
> >     {
> >       camera: {
> >          up: [ 0, 1, 0 ],


> The  first thing bothering me is the combination of colons and brace characters
> in some places or maybe rather that it seems it can't be used the same  way
> elsewhere?
> Would we have to write camera: {
> It would seem a little cluttered to have to use a : for just specifying the
> opening of a block. do we have to ?

I would say that some of these things will have to be looked at from the
perspective of
1. the developer / parser
2. the end user

I would like it if we could dispense with some of the brackets altogether, and
just have a LF/CR/NL or new keyword signal the end of a statement.
On the other hand, I _would_ like to have explicit endings for code blocks, such
as
#endcamera
#endif
#endfor
#endwhile

as I think that overall it would be in the long run easier from both
perspectives to follow and debug code.

> > One possible change to the syntax could be the use of regular braces
> > around list items instead of square brackets to specifically denote
> > vectors, if only to make it more pleasant to read.

There has been some discussion about typing and automatic vector promotion.
Getting rid of brackets and braces altogether would make a little less typing to
do, but maybe it would be worth it to lose that benefit if we had to specify
things like vec2, vec3, vec4 - if only to keep it at the forefront of our minds
what sort of values we're dealing with in any given instance.


> > I'd also love to add ranges to the set of types, using a syntax akin to
> > this:
> >
> >     [ 1 .. 20 ] // range from 1 to 20, both inclusive
> >     ( 1 .. 20 ) // range from 1 to 20, both exclusive
> >     [ 1 .. 20 ) // range from 1 inclusive to 20 exclusive
> >     ( 1 .. 20 ] // range from 1 exclusive to 20 inclusive

Ranges would be very nice, but maybe I would like to get rid of the parentheses
in favor of a leading keyword, so that we could instead have all manner of
parentheses available for use in grouping terms in equations without making
parsing (more of) a complicated ordeal.

so, the keywords for the above examples might be ii, ee, ie, ei.

then we could write equations like   val = [sin (x+3) / pi] + (tau/6) -
abs{cos[(q/360)+(<n/0.5>+0.5)]};
It would also be nice to drop the requirement for #declare and just write
     x=3;


> > symbols as (entirely optional) syntactic sugar.

This would be very nice, especially for placing the text/symbol in the render.

The same would go for a mechanism for exposing the text of a parsed line of code
to the SDL.
What I mean by that is to have a mechanism similar to that in a spreadsheet
whereby if cell A3 has (x+1)/10 in it, then formula (A3) returns the string
"(x+1)/10"


> But with the prerequisites that they should have an explicit
> alternative for when we don't know or have any internet to check for the code to
> type. most people never enter a unicode special number their whole life. but
> maybe the parsing times could really be worth that learning?

We could do that with an include file, like we have with functions.inc -
symbol.inc could have #declare sym_nabla = symbol (U+2207); or however it would
get coded.

Post a reply to this message