1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
|
# Modules
Limbo supports compartmentalization of functionality through the dynamic loading and unloading of names and definitions through modules.
Disclaimer: At the time of writing I am not exceptionally well-versed with modules in Limbo. All assertions should be taken with a grain of salt.
## Source
### persons.m:1,11
Function definitions:
- init() persons.b:7,9
- mkperson() persons.b:11,13
- getpop() persons.b:15,18
Note: In a way, a module definition acts as an interface which dictates which functions, variables, and types are accessible from outside the module's implementation proper.
### towns.m:1,14
Function definitions:
- init() towns.b:5,7
- mktown() towns.b:9,11
### modules.b:25,29
### modules.b:31,39
### modules.b:41,45
Note: The type `Person` is imported at modules.b:13.
## Demo
; modules
0
0
1
0
Name: Mars
Size: 2
Members:
→ Spike
→ Ed
;
## Exercises
- Can you access `persons->population` from `modules`?
- Could you make a global variable by placing said variable in its respective module definition?
- What happens if you remove the `import` statements for `Person` and `Town` in various `.b` files?
- What happens if you include `persons.m` in `modules.b`?
- What happens if you include `persons.m` in `modules.b` and remove the include for `persons.m` in `towns.m`?
|