Bump the version number mentioned in the Appendix.
Chris Pressey
2 years ago
| 359 | 359 | |
| 360 | 360 | #### On the implementation of names. |
| 361 | 361 | |
| 362 | One way to implement names as defined in Lariat 0.2 is to use _qualified names_. | |
| 362 | One way to implement names as defined in Lariat 0.3 is to use _qualified names_. | |
| 363 | 363 | A qualified name is an ordered list of _name segments_, where each name segment |
| 364 | 364 | is what a name was in Lariat 0.1, i.e. the only operation we require name segments |
| 365 | 365 | to support is comparison of two name segments for equality. (Comparing two |
| 383 | 383 | |
| 384 | 384 | So we can assume an algorithm like this is in use. But ultimately, any |
| 385 | 385 | implementation which satisfies the two operations required of names |
| 386 | (`equal` and `fresh`) is acceptable. We provide this concrete representation | |
| 387 | and algorithm here partly because a trivial concrete representation as used | |
| 388 | in Lariat 0.1 is _not_ sufficient for implementing names (as there is no | |
| 389 | derivable way to obtain a fresh name when needed, without relying on some | |
| 390 | external fresh name supply) and we wanted to show that there was at least | |
| 386 | (`equal` and `fresh`) is acceptable. This concrete representation and | |
| 387 | algorithm is provided here partly because a trivial concrete representation | |
| 388 | as used in Lariat 0.1 is _not_ sufficient for implementing names (as there | |
| 389 | is no derivable way to obtain a fresh name when needed, without relying on | |
| 390 | some external fresh name supply) and I wanted to show that there was at least | |
| 391 | 391 | _some_ concrete representation which fulfills the requirements. |