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 
no additional effect.)

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

Post a reply to this message