Goal
Keep actively looking for places where IR can do better than syntax inherited from languages that were designed around a much smaller keyboard.
This is not a mandate to replace familiar notation for novelty's sake. . and $, for example, have been familiar object/member-access notation for decades and do not currently need changing. The point is to notice cases where an older design is awkward mainly because its authors were constrained to the characters that were easy to type at the time.
IR has more freedom:
- a dedicated composition operator such as
∘
- a native pipe for post-composition / value flow
- additional mathematically or visually appropriate symbols when a genuinely distinct operation needs one
- a custom programming keyboard, so useful brackets and Unicode operators need not be treated as prohibitively expensive to type
Questions to keep asking as the language grows:
- Is this syntax good on its own merits, or merely conventional because of historical ASCII/keyboard constraints?
- Are two different operations sharing punctuation because an older language ran out of convenient symbols?
- Would a distinct symbol make the execution path or mathematical meaning substantially clearer?
- Conversely, would replacing a familiar symbol merely make the language stranger without improving comprehension?
- Are users repeatedly stumbling over a notation choice? If so, revisit it even if it was once considered settled.
Prefer concrete evidence over aesthetic churn. Familiar notation can stay familiar when it works. But do not freeze accidental historical constraints into IR simply because other languages did so.
This should be an ongoing language-design audit rather than a one-time Unicode conversion project. When a recurring source of confusion appears, be willing to change the surface language if a better notation genuinely improves use.
Goal
Keep actively looking for places where IR can do better than syntax inherited from languages that were designed around a much smaller keyboard.
This is not a mandate to replace familiar notation for novelty's sake.
.and$, for example, have been familiar object/member-access notation for decades and do not currently need changing. The point is to notice cases where an older design is awkward mainly because its authors were constrained to the characters that were easy to type at the time.IR has more freedom:
∘Questions to keep asking as the language grows:
Prefer concrete evidence over aesthetic churn. Familiar notation can stay familiar when it works. But do not freeze accidental historical constraints into IR simply because other languages did so.
This should be an ongoing language-design audit rather than a one-time Unicode conversion project. When a recurring source of confusion appears, be willing to change the surface language if a better notation genuinely improves use.