POV-Ray : Newsgroups : povray.pov4.discussion.general : Random POV-Ray 4 SDL proposal, #1 : Re: Random POV-Ray 4 SDL proposal, #1 Server Time 1 Aug 2021 23:55:09 EDT (-0400)
 Re: Random POV-Ray 4 SDL proposal, #1
 From: clipka Date: 9 Jun 2021 20:30:31 Message: <60c15d27\$1@news.povray.org>
```Am 09.06.2021 um 20:13 schrieb Bald Eagle:

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

I think we can have both.

The style of range notation is deliberately chosen to make it easy to
determine what is the start of something and what the end; for instance,
I personally prefer the following alternative notation because I find it
more intuitive with respect to which end is "inclusive" and which is
"exclusive", but _that_ would indeed seriously complicate parsing:

[ 1 .. 20 ] // range from 1 to 20, both inclusive
] 1 .. 20 ] // range from 1 exclusive to 20 inclusive

As for the proposed syntax further above, distinguishing an arbitrary
mathematical expression from a range should be easy: All the parser
needs to do is look at the "..", which we can take as an operator that
takes two numeric values and returns what we might call a "naked range".
Parentheses and/or brackets around such a "naked range" would then
convert that into what we might call a "qualified range". (Further
wrapping a "qualified range" in more parentheses or brackets would have

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

Explicit ASCII alternatives, hard-baked into the language, would be a
must, IMO. As I mentioned, Unicode symbols would be syntactic sugar. The
ASCII constructs would be the real deal, while the Unicode symbols would
be considered shortcuts.
```