RN we have components like New, Lock or Field that are used by both user and compiler. Not just that might confuse user (which path to go?) but also mixes two separate responsibilities together
Serve as implementation detail for compiler
Serve as a tool for end user
For instance, user can set incorrect path to Field. Should field have err outport then? It's weird isn't it? Program should not compile if path is wrong. It's easy when we use syntax sugar . for that, but when we handle Field usage in a special case, that's a (unnecessary) special case for the compiler.
Proposal
Separate stuff like new, lock, field, etc (everything compiler uses for desugaring basically) from the ones that just should be available in the global scope.
Should something be in the global scope it's the question itself but for another issue.
The question that is related to this issue is - should user be able to use these "low-level" components at all? We can e.g. throw compilation error when user tries to import internal (e.g.) package.
Well, it's not clear. If we wanna go that way, we must be sure our syntax is good enough to cover all the cases needed. And even then, "syntax sugar" is a conception that mean - it must always be possible to write desugared version manually.
I see RN 2 solutions to this:
It's not "desugared" version of the program, it's "lower level representation" (and user can't write it manually)
Allow user to use internal but document it well so it's clear that it should not be done
Second approach is more flexible in a way that we can cover all the cases our syntax is not powerful enough (yet?). We can also add linter rule that will throw warnings on using unsafe/internal stuff.
Problem
RN we have components like
New,LockorFieldthat are used by both user and compiler. Not just that might confuse user (which path to go?) but also mixes two separate responsibilities togetherFor instance, user can set incorrect
pathtoField. Should field haveerroutport then? It's weird isn't it? Program should not compile if path is wrong. It's easy when we use syntax sugar.for that, but when we handleFieldusage in a special case, that's a (unnecessary) special case for the compiler.Proposal
Separate stuff like new, lock, field, etc (everything compiler uses for desugaring basically) from the ones that just should be available in the global scope.
Should something be in the global scope it's the question itself but for another issue.
The question that is related to this issue is - should user be able to use these "low-level" components at all? We can e.g. throw compilation error when user tries to import
internal(e.g.) package.Well, it's not clear. If we wanna go that way, we must be sure our syntax is good enough to cover all the cases needed. And even then, "syntax sugar" is a conception that mean - it must always be possible to write desugared version manually.
I see RN 2 solutions to this:
internalbut document it well so it's clear that it should not be doneSecond approach is more flexible in a way that we can cover all the cases our syntax is not powerful enough (yet?). We can also add linter rule that will throw warnings on using unsafe/internal stuff.
Related to #683