clipka <ano### [at] anonymousorg> wrote:
> As a starting point, I'll take an existing language

Okay, Maybe what follows is incompatible with this language I know nothing
about, so ignore my remarks in that eventuality because I do value that idea of
leveraging the best and closest standard if possible.


> A simple POV-Ray scene described in this format might look like this:
[...]
>     {
>       camera: {
>          up: [ 0, 1, 0 ],
>          right: [ 1.33, 0, 0 ],
>          direction: [ 0, 0, -1 ],
>          location: [ 0, 0, 5 ],
>          look_at: [ 0, 0, 0 ]
>       },
>       objects: [
>         light_source {
>           location: [ -100, 100, 100 ],
>           colour: #FFFFFF
>         },
>         sphere {
>           location: [ 0, 0, 0 ],
>           radius: 1,
>           texture: {
>             pigment: {
>               colour: #FFFFFF
>             }
>           }
>         }
>       ]
>     }


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 ? ... why not:

       camera{
          up: [ 0, 1, 0 ],
          right: [ 1.33, 0, 0 ],
          direction: [ 0, 0, -1 ],
          location: [ 0, 0, 5 ],
          look_at: [ 0, 0, 0 ]
       },

Also for same reason, would the comma after the brace really be necessary ?



> Next we need variables; again we don't want them to collide with our
> unquoted strings, so I'll use just about the same trick, except that I
> use "@" to refer to variables.

Fine,

>       center: @@Bar // look what I just did there

I'm not sure I understand, maybe that's why, but it looks a little barbarian to
my delicate profane eye :-) Does json force to specify like this instead of some
"object" dot lookup operator?

> There. Behold your new SDL, chilren of POV-Ray.

Yay ! great to see some direction, and a great start !

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

I believe readability would suffer and prefer your proposition versus curly
braces everywhere whith no rythmic to distinguish what's inside what though the
too-many-different-enclosing-signs margin is probably easily reached, so <>
could go away as far as i'm concerned

> 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

Personally I think this looks pretty cool! But again I'm no expert at all.

> symbols as (entirely optional) syntactic sugar.

Sounds awesome as well and a breath of fresh air for such a feature rich
program, it also goes well with the cypher obscure reputation of POV, except for
once it would have some real benefits, I assume, in code parsing computation
times ?  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?

This brings to my mind the topic even outside of the mathematical field of some
unicode symbols or even some more common non ascii characters, sorry if too off
topic for lack of terminology and specialists concepts here, but my naive
expectations for POV sdl of my dreams :

a)It should strive to still look intuitive and elegant to non programmers,
preferably one & looks better than two or three && or @@  except where
conventions are long there in several mainstream languages like comments with
doubled chars // for many languages and some alternative doubled sign in many
more others.

b)May we try to keep it easy to type with less modifier keys across the two or
three most used keyboard layouts, since we don't want povers to have carpal
tunnel. (but probably the most cryptic unicode are easier to call by their id
number than some of the characters available of the keyboard layouts requiring
to type a space before they appear and one of two alt keys etc...

I'm getting lost in that stream of thoughts, wishes and good intentions, so I
should stop especially as I trust the experts around here a lot more !

Thanks for giving this a lot of thought!

Post a reply to this message