Open ehuss opened 5 years ago
cc @petrochenkov
Just to kick off a little discussion of the outline: a long while back I started an outline here: https://github.com/ehuss/reference/commit/bb2e84bf3b84f4e7a9b2532feae82659c603d894
Since I think this will overall be a meaty topic, I think it would be good to split it into separate files from the start.
I think the "Paths" chapter should be moved underneath name resolution, since it doesn't really belong in the lexical chapter.
Some high-level questions:
I was thinking the "Definitions" chapter would list all the things that can introduce an identifier into scope.
I think it would be good to have at least a list of definitions with links to other chapters, even if majority of the text will be elsewhere.
What to call the things that identifiers can refer to?
They are called NameBinding
in the compiler, but it's a very old and sufficiently inconsistent name.
"Name introduction" perhaps? The introduction may either be a "name definition", or an "import"/"reexport" referring to a different name introduction.
Just to add a couple more questions:
Deref
for pointers.I like the term introduction
for the places a binding/name is introduced. Also +1 on having a central list that links to more descriptions in the specific chapters.
For "elements", we could just be informal and say "parts of a program".
Can we pick a better term than "name resolution"?
In C++ it's officially called "name lookup", for example.
Do we want to call them "names" or "bindings"?
I would personally prefer "names". AFAIK, the term "bindings" is only used for local variables in the user-facing documentation, and all those "variable vs binding" explanations never made sense to me.
AFAIK, the term "bindings" is only used for local variables in the user-facing documentation,
Yes. That is entirely correct and I am way too tired.
Name resolution should be documented. This is a large topic. A few pieces I can think of:
macro_use
andmacro_export
.macro_use
prelude, the "tool prelude" (I think), etc. DONE #937no_implicit_prelude
should clarify which preludes are not included. DONE #937use
handle something that is available in multiple namespaces (such as a module and a type).