Question
IR does not need to change . or $ now. Both are familiar and neither is currently a problem. But the distinction should eventually be made explicit rather than inherited accidentally from R or other languages.
Things to examine:
- What exactly does
x$name mean: named member lookup, environment lookup, column access, method lookup, or some deliberately shared notion?
- If
x.name is supported, what semantic operation is it expressing that is genuinely different from $?
- How should either notation interact with generic functions and multiple dispatch? Member lookup and dispatch can feel similar to the programmer, but their execution paths are different.
- Can the execution pathway remain obvious from the surface syntax?
Do not change either syntax merely for tidiness. This is a later design/clarification issue: document the semantics first, then change something only if a real ambiguity or unnecessary duplication emerges.
Question
IR does not need to change
.or$now. Both are familiar and neither is currently a problem. But the distinction should eventually be made explicit rather than inherited accidentally from R or other languages.Things to examine:
x$namemean: named member lookup, environment lookup, column access, method lookup, or some deliberately shared notion?x.nameis supported, what semantic operation is it expressing that is genuinely different from$?Do not change either syntax merely for tidiness. This is a later design/clarification issue: document the semantics first, then change something only if a real ambiguity or unnecessary duplication emerges.