gotypes: minor fixes
Change-Id: Ie730f983c12a20c6c50e289650e230a05b1c782b
Reviewed-on: https://go-review.googlesource.com/17972
Reviewed-by: Alan Donovan <adonovan@google.com>
diff --git a/gotypes/README.md b/gotypes/README.md
index d551420..86c9674 100644
--- a/gotypes/README.md
+++ b/gotypes/README.md
@@ -222,7 +222,7 @@
Second, the program parses the input string.
More realistic packages contain several source files, so the parsing
-step must be repeated for each one, or better still, done in parallel.
+step must be repeated for each one, or better, done in parallel.
Third, it creates a `Config` that specifies type-checking options.
Since the _hello, world_ program uses imports, we must indicate
how to locate the imported packages.
@@ -304,11 +304,11 @@
-Objects are represented by the `Object` interface, shown below:
+Objects are represented by the `Object` interface:
type Object interface {
- Name() string // package local object name
+ Name() string // package-local object name
Exported() bool // reports whether the name starts with a capital letter
Type() Type // object type
Pos() token.Pos // position of object identifier in declaration
@@ -338,7 +338,7 @@
offset, though usually we just call its `String` method:
- fmt.Fprintln(fset.Position(obj.Pos())) // "hello.go:10:6"
+ fmt.Println(fset.Position(obj.Pos())) // "hello.go:10:6"
Not all objects carry position information.
@@ -349,7 +349,7 @@
-There are eight kinds of objects in the Go type checker.
+There are eight kinds of object in the Go type checker.
Most familiar are the kinds that can be declared at package level:
constants, variables, functions, and types.
Less familiar are statement labels, imported package names
@@ -388,6 +388,7 @@
[Scopes](#scopes).
Fields and methods are not found in the lexical environment, so
their objects have no `Parent`.
+<!-- TODO check this -->
@@ -702,8 +703,8 @@
universe block at the root, the package blocks beneath it, the file
blocks beneath them, and then any number of local blocks beneath the
files.
-The following methods of `Scope` make this tree structure
-accessible and navigable:
+We can access and navigate this tree structure with the following
+methods of `Scope`:
func (s *Scope) Parent() *Scope
@@ -768,7 +769,7 @@
`Pos` and `End` report the `Scope`'s start and end
-position which, for explicit blocks, are coincident with its curly
+position which, for explicit blocks, coincide with its curly
braces.
`Contains` is a convenience method that reports whether a
position lies in this interval.
@@ -898,6 +899,7 @@
PkgName ✔
Label ✔
+
# Initialization Order
@@ -951,7 +953,8 @@
order among them is not specified.
That is, any topological order of the import graph will do.
The `(*Package).Imports` method returns the set of direct
-dependencies of a package, in an unspecified order.
+dependencies of a package.
+>>>>>>> 637ffe0981073879a95f848fd9528efe9231bed9
# Types
@@ -1066,7 +1069,7 @@
The `Name` method returns the name of the type, such as
`"float64"`, and the `Info` method returns a bitfield that
encodes information about the type, such as whether it is signed or
-unsigned, integer or floating point, real or complex.
+unsigned, integer or floating point, or real or complex.
@@ -1135,6 +1138,7 @@
Each field is a `Var` object whose `IsField` method returns true.
Field objects have no `Parent` scope, because they are
resolved through selections, not through the lexical environment.
+<!-- TODO check this -->
@@ -1172,7 +1176,7 @@
the AST---neither of which is possible for objects loaded from compiler
export data---it is not possible to ascertain that `x` was declared as
part of `T`.
-The type checker computes the exact same data structures given this input:
+The type checker builds the exact same data structures given this input:
type T U
@@ -1264,7 +1268,7 @@
A type declaration creates a `TypeName` object, and the type of
that object is a `Named`.
These two entities, an object and a type, are distinct but closely
-related, and they exist in one-to-one correpondence.
+related, and they exist in one-to-one correspondence.
type Named struct{ ... }
@@ -1405,15 +1409,15 @@
}
-No entry is recorded for identifiers since the `Defs` and
+No entries are recorded for identifiers since the `Defs` and
`Uses` maps provide more information about them.
-Also, no entry is recorded for pseudo-expressions like
+Also, no entries are recorded for pseudo-expressions like
`*ast.KeyValuePair` or `*ast.Ellipsis`.
The value of the `Types` map is a `TypeAndValue`, which
-(unsurprisingly) holds the `Type` and value of the expression, and in
+(unsurprisingly) holds the type and value of the expression, and in
addition, its _mode_.
The mode is opaque, but has predicates to answer questions such as:
Does this expression denote a value or a type? Does this value have an
@@ -1437,7 +1441,7 @@
func (TypeAndValue) IsNil() bool // e.g. "nil"
func (TypeAndValue) Addressable() bool // e.g. "a[i]" but not "f()", "m[key]"
func (TypeAndValue) Assignable() bool // e.g. "a[i]", "m[key]"
- func (TypeAndValue) HasOk() bool // e.g. "<-ch", "m[key]"
+ func (TypeAndValue) HasOk() bool // e.g. "<-ch", "m[key]"
The statement below inspects every expression within the AST of a single
@@ -1707,12 +1711,9 @@
The `addressable` flag should be set if the receiver is a
_variable_ of type `T`, since in a method selection on a
-variable, an implicit address-of operation (`&`) may occur.
+variable, an implicit address-of operation (`&`) may occur.
The flag indicates whether the methods of type `*T` should be
considered during the lookup.
-
-
-
(You may wonder why this parameter is necessary. Couldn't clients
instead call `LookupFieldOrMethod` on the pointer type `*T`
if the receiver is a `T` variable? The answer is that if
@@ -1826,7 +1827,7 @@
func (s *MethodSet) Lookup(pkg *Package, name string) *Selection
-The `Len` and `At` methods access a a list of
+The `Len` and `At` methods access a list of
`Selections`, all of kind `MethodVal`, ordered by `Id`.
The `Lookup` function allows lookup of a single method by
name (and package path, as explained in the previous section).
@@ -2087,7 +2088,7 @@
All numeric `Value`s, whether integer or floating-point, signed or
-unsigned, or real or complex, are represented more precisely than the
+unsigned, or real or complex, are represented more precisely than
ordinary Go types like `int64` and `float64`.
Internally, the `go/constant` package uses multi-precision data types
like `Int`, `Rat`, and `Float` from the `math/big` package so that
diff --git a/gotypes/go-types.md b/gotypes/go-types.md
index a00b0fd..b13e7e7 100644
--- a/gotypes/go-types.md
+++ b/gotypes/go-types.md
@@ -148,7 +148,7 @@
Second, the program parses the input string.
More realistic packages contain several source files, so the parsing
-step must be repeated for each one, or better still, done in parallel.
+step must be repeated for each one, or better, done in parallel.
Third, it creates a `Config` that specifies type-checking options.
Since the _hello, world_ program uses imports, we must indicate
how to locate the imported packages.
@@ -221,11 +221,11 @@
-Objects are represented by the `Object` interface, shown below:
+Objects are represented by the `Object` interface:
type Object interface {
- Name() string // package local object name
+ Name() string // package-local object name
Exported() bool // reports whether the name starts with a capital letter
Type() Type // object type
Pos() token.Pos // position of object identifier in declaration
@@ -255,7 +255,7 @@
offset, though usually we just call its `String` method:
- fmt.Fprintln(fset.Position(obj.Pos())) // "hello.go:10:6"
+ fmt.Println(fset.Position(obj.Pos())) // "hello.go:10:6"
Not all objects carry position information.
@@ -266,7 +266,7 @@
-There are eight kinds of objects in the Go type checker.
+There are eight kinds of object in the Go type checker.
Most familiar are the kinds that can be declared at package level:
constants, variables, functions, and types.
Less familiar are statement labels, imported package names
@@ -305,6 +305,7 @@
[Scopes](#scopes).
Fields and methods are not found in the lexical environment, so
their objects have no `Parent`.
+<!-- TODO check this -->
@@ -578,8 +579,8 @@
universe block at the root, the package blocks beneath it, the file
blocks beneath them, and then any number of local blocks beneath the
files.
-The following methods of `Scope` make this tree structure
-accessible and navigable:
+We can access and navigate this tree structure with the following
+methods of `Scope`:
func (s *Scope) Parent() *Scope
@@ -644,7 +645,7 @@
`Pos` and `End` report the `Scope`'s start and end
-position which, for explicit blocks, are coincident with its curly
+position which, for explicit blocks, coincide with its curly
braces.
`Contains` is a convenience method that reports whether a
position lies in this interval.
@@ -717,6 +718,7 @@
PkgName ✔
Label ✔
+
# Initialization Order
@@ -770,7 +772,8 @@
order among them is not specified.
That is, any topological order of the import graph will do.
The `(*Package).Imports` method returns the set of direct
-dependencies of a package, in an unspecified order.
+dependencies of a package.
+>>>>>>> 637ffe0981073879a95f848fd9528efe9231bed9
# Types
@@ -885,7 +888,7 @@
The `Name` method returns the name of the type, such as
`"float64"`, and the `Info` method returns a bitfield that
encodes information about the type, such as whether it is signed or
-unsigned, integer or floating point, real or complex.
+unsigned, integer or floating point, or real or complex.
@@ -954,6 +957,7 @@
Each field is a `Var` object whose `IsField` method returns true.
Field objects have no `Parent` scope, because they are
resolved through selections, not through the lexical environment.
+<!-- TODO check this -->
@@ -991,7 +995,7 @@
the AST---neither of which is possible for objects loaded from compiler
export data---it is not possible to ascertain that `x` was declared as
part of `T`.
-The type checker computes the exact same data structures given this input:
+The type checker builds the exact same data structures given this input:
type T U
@@ -1083,7 +1087,7 @@
A type declaration creates a `TypeName` object, and the type of
that object is a `Named`.
These two entities, an object and a type, are distinct but closely
-related, and they exist in one-to-one correpondence.
+related, and they exist in one-to-one correspondence.
type Named struct{ ... }
@@ -1224,15 +1228,15 @@
}
-No entry is recorded for identifiers since the `Defs` and
+No entries are recorded for identifiers since the `Defs` and
`Uses` maps provide more information about them.
-Also, no entry is recorded for pseudo-expressions like
+Also, no entries are recorded for pseudo-expressions like
`*ast.KeyValuePair` or `*ast.Ellipsis`.
The value of the `Types` map is a `TypeAndValue`, which
-(unsurprisingly) holds the `Type` and value of the expression, and in
+(unsurprisingly) holds the type and value of the expression, and in
addition, its _mode_.
The mode is opaque, but has predicates to answer questions such as:
Does this expression denote a value or a type? Does this value have an
@@ -1256,7 +1260,7 @@
func (TypeAndValue) IsNil() bool // e.g. "nil"
func (TypeAndValue) Addressable() bool // e.g. "a[i]" but not "f()", "m[key]"
func (TypeAndValue) Assignable() bool // e.g. "a[i]", "m[key]"
- func (TypeAndValue) HasOk() bool // e.g. "<-ch", "m[key]"
+ func (TypeAndValue) HasOk() bool // e.g. "<-ch", "m[key]"
The statement below inspects every expression within the AST of a single
@@ -1408,12 +1412,9 @@
The `addressable` flag should be set if the receiver is a
_variable_ of type `T`, since in a method selection on a
-variable, an implicit address-of operation (`&`) may occur.
+variable, an implicit address-of operation (`&`) may occur.
The flag indicates whether the methods of type `*T` should be
considered during the lookup.
-
-
-
(You may wonder why this parameter is necessary. Couldn't clients
instead call `LookupFieldOrMethod` on the pointer type `*T`
if the receiver is a `T` variable? The answer is that if
@@ -1527,7 +1528,7 @@
func (s *MethodSet) Lookup(pkg *Package, name string) *Selection
-The `Len` and `At` methods access a a list of
+The `Len` and `At` methods access a list of
`Selections`, all of kind `MethodVal`, ordered by `Id`.
The `Lookup` function allows lookup of a single method by
name (and package path, as explained in the previous section).
@@ -1687,7 +1688,7 @@
All numeric `Value`s, whether integer or floating-point, signed or
-unsigned, or real or complex, are represented more precisely than the
+unsigned, or real or complex, are represented more precisely than
ordinary Go types like `int64` and `float64`.
Internally, the `go/constant` package uses multi-precision data types
like `Int`, `Rat`, and `Float` from the `math/big` package so that
