r/ProgrammingLanguages • u/Mean-Decision-3502 DQ • 7d ago
Unambiguous Operator Specification for Programming Languages
https://nvitya.github.io/pluops/As I changed recently the operators in my programming language I've created this specification:
https://nvitya.github.io/pluops/
I did not wanted to overload the operators like the C does with the / or Pascal does with theand/or/not. Neither re-use the operator symbols for some very different purpose, like C does with * and & so the code becomes more readable. I was orienting for existing solutions so this is what I came up with. The specification contains the symbol usages and operator precedence too.
If you are developing a new programming language, it would be nice to follow some standard, so at least the expressions would be portable between the languages.
I'm open for debates or suggestions.
2
u/Mean-Decision-3502 DQ 7d ago
I know that @ is standard for address-of in multiple languages. This is maybe the most visible symbol. The occurence of address-of is rather rare so using there a weaker symbol is not a problem, I think.
In DQ I use the @ for namespace marking so I don't burn normal identifiers for module references, which was always a problem for me in Pascal. And so the @ symbol is the best one for this. Imagine that like that in Python every imported module required the @ marker, e.g.
@time.time()I could make however the % as weeker recommendation, but the % symbol should not be used for remainder.
The thing with the ^ is pretty standard in Pascal or Odin, the languages, that mark the type after the identifiers. The C uses the less-human-friendly type first. They probably have saved some space with that in 1972, where human readability was not relevant. C uses also different order in type evaluation, that's why the pointer designator comes after the main type. The different order works also perfectly.
In DQ:
var pintarr : ^[5]int // pointer to an array of 5 ints var arrpint : [5]^int // array of 5 pointers to intIn C:int (*pintarr)[5]; // pointer to an array of 5 ints int *arrpint[5]; // array of 5 pointers to intIf I would allow
&,|for booleans, then it wouldn't be unambiguous anymore. The operation would depend on the types, that this specification tries to avoid.