Skip to content

Commit b339703

Browse files
authored
docs(interrealm): fix small typos (#4236)
1 parent f6f3e88 commit b339703

File tree

1 file changed

+20
-20
lines changed

1 file changed

+20
-20
lines changed

docs/resources/gno-interrealm.md

Lines changed: 20 additions & 20 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
# Interrealm Specification
22

3-
Gno extends Go's type system with a interrealm rules. These rules can be
3+
Gno extends Go's type system with interrealm rules. These rules can be
44
checked during the static type-checking phase (but at the moment they are
55
partially dependent on runtime checks).
66

@@ -24,7 +24,7 @@ A function declared in a realm package when called:
2424

2525
The `crossing()` statement must be the first statement of a function's body.
2626
It is illegal to use anywhere else, and cannot be used in p packages. Functions
27-
that begin with the `crossing()` statement are called "crossing" functions".
27+
that begin with the `crossing()` statement are called "crossing functions".
2828

2929
A crossing function declared in a realm different than the last explicitly
3030
crossed realm *must* be called like `cross(fn)(...)`. That is, functions of
@@ -54,7 +54,7 @@ else's pen it is still your signature; signature:pen :: current:borrowed.
5454
A crossing method declared in a realm cannot modify the receiver if the object
5555
resides in a different realm. However not all methods are required to be
5656
crossing methods, and crossing methods may still read the state of the
57-
receiver (and in general anything reacheable is readible).
57+
receiver (and in general anything reachable is readable).
5858

5959
New unreal objects reachable from the borrowed realm (or current realm if there
6060
was no method call that borrowed) become persisted in the borrowed realm (or
@@ -68,7 +68,7 @@ MsgCall can only call (realm) crossing functions.
6868
MsgRun will run a file's `main()` function in the user's realm and may call
6969
both crossing functions and non-crossing functions.
7070

71-
A realm package's initialization (including init() calls) execute with current
71+
A realm package's initialization (including `init()` calls) execute with current
7272
realm of itself, and it `std.PreviousRealm()` will panic unless the call stack
7373
includes a crossing function called like `cross(fn)(...)`.
7474

@@ -100,7 +100,7 @@ implicit and generally not obvious without more language features.
100100

101101
Code declared in p packages (or declared in "immutable" realm packages) can
102102
help different realms enforce contracts trustlessly, even those that involve
103-
the caller's current realm. Otherwise two mutable (upgreadeable) realms cannot
103+
the caller's current realm. Otherwise two mutable (upgradeable) realms cannot
104104
export trust unto the chain because functions declared in those two realms can
105105
be upgraded.
106106

@@ -109,19 +109,19 @@ future Gno versions.
109109

110110
### Usage
111111

112-
P package code cannot containing crossing functions, nor use crossing(). P
112+
P package code cannot contain crossing functions, nor use `crossing()`. P
113113
package code also cannot import R realm packages. But code can call named
114114
crossing functions e.g. those passed in as parameters.
115115

116-
You must declare a public realm function to be crossing() if it is intended to
116+
You must declare a public realm function to be `crossing()` if it is intended to
117117
be called by end users, because users cannot MsgCall non-crossing functions
118118
(for safety/consistency) or p package functions (there's no point).
119119

120120
Utility functions that are a common sequence of non-crossing logic can be
121121
offered in realm packages as non-crossing functions. These can also import and
122122
use other realm utility non-crossing functions; whereas p packages cannot
123123
import realm packages at all. And convenience/utility functions that are being
124-
staged before publishing as permanent p code should also reside in upgreadeable
124+
staged before publishing as permanent p code should also reside in upgradeable
125125
realms.
126126

127127
Generally you want your methods to be non-crossing. Because they should work
@@ -141,7 +141,7 @@ overrides for testing are defined in `testing/stdlibs/std/std.gno/go`. All
141141
stdlibs functions are available unless overridden by the latter.
142142

143143
`std.CurrentRealm()` shifts to `std.PreviousRealm()` if and only if a function
144-
is called like cross(fn)(...).
144+
is called like `cross(fn)(...)`.
145145

146146
#### MsgCall
147147

@@ -212,7 +212,7 @@ func main() {
212212
}
213213
```
214214

215-
Notice in gnovm/pkg/gnolang/misc.go, the following:
215+
Notice in `gnovm/pkg/gnolang/misc.go`, the following:
216216

217217
```go
218218
// For keeping record of package & realm coins.
@@ -241,7 +241,7 @@ func DerivePkgBech32Addr(pkgPath string) crypto.Bech32Address {
241241
```
242242

243243
These function names are distinct from what is available in Gno
244-
from stdlibs/std/crypto.gno:
244+
from `stdlibs/std/crypto.gno`:
245245

246246
```go
247247
// Returns a crypto hash derived pkgPath, unless pkgPath is a MsgRun run path,
@@ -255,14 +255,14 @@ func DerivePkgAddr(pkgPath string) Address {
255255
1. `std.DerivePkgAddr("gno.land/r/name123/realm")` - bech32 from hash(path)
256256
2. `std.DerivePkgAddr("gno.land/r/g1user/run")` - bech32 substring "g1user"
257257

258-
Therefore in the MsgRun file's init() function the previous realm and current
258+
Therefore in the MsgRun file's `init()` function the previous realm and current
259259
realm have different pkgpaths (the origin caller always has empty pkgpath) but
260260
the address is the same.
261261

262262
#### MsgAddPackage
263263

264264
During MsgAddPackage `std.PreviousRealm()` refers to the package deployer both
265-
in gloval var decls as well as inside `init()` functions. After that the
265+
in global var decls as well as inside `init()` functions. After that the
266266
package deployer is no longer provided, so packages need to remember the
267267
deployer in the initialization if needed.
268268

@@ -320,9 +320,9 @@ The `gnovm/tests/stdlibs/testing/context_testing.gno` file provides functions
320320
for overriding frame details from Gno test code.
321321

322322
`testing.SetRealm(std.NewUserRealm("g1user"))` is identical to
323-
`testing.SetOriginCaller("g1user"). Both will override the Gno frame to make it
323+
`testing.SetOriginCaller("g1user")`. Both will override the Gno frame to make it
324324
appear as if the current frame is the end user signing with a hardware signer.
325-
Both will also set ExecContext.OriginCaller to that user. One of these will
325+
Both will also set `ExecContext.OriginCaller` to that user. One of these will
326326
become deprecated.
327327

328328
#### Gno test cases with `_test.gno` like `TestFoo(t *testing.T)`
@@ -421,9 +421,9 @@ func main() {
421421

422422
#### Future Work
423423

424-
std.SetOriginCaller() should maybe be deprecated in favor of
425-
std.SetRealm(std.NewUserRealm(user)) renamed to
426-
std.SetRealm(std.NewOriginRealm(user)).
424+
`std.SetOriginCaller()` should maybe be deprecated in favor of
425+
`std.SetRealm(std.NewUserRealm(user))` renamed to
426+
`std.SetRealm(std.NewOriginRealm(user))`.
427427

428-
std.SetRealm(std.NewCodeRealm(path)) renamed to
429-
std.SetRealm(std.NewPackageRealm(path)).
428+
`std.SetRealm(std.NewCodeRealm(path))` renamed to
429+
`std.SetRealm(std.NewPackageRealm(path))`.

0 commit comments

Comments
 (0)