From 69729b11d0a2bcd0e82cc81103f376e0df2b74f8 Mon Sep 17 00:00:00 2001 From: Gabor Greif Date: Tue, 16 Jan 2024 16:51:01 +0100 Subject: [PATCH] chore: update `design/WhitePaper.md` (#4366) Addes a link to resolved suggestion, fixed a typo. --- design/WhitePaper.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/design/WhitePaper.md b/design/WhitePaper.md index 0537e035ab0..987f6c3181a 100644 --- a/design/WhitePaper.md +++ b/design/WhitePaper.md @@ -413,7 +413,7 @@ The relation `<:infer` infers the rhs type substitution, as for implict type arg Challenge: One issue with the above is that `T1` does not generally determine all type parameters of `chain`, particularly the ones only occurring in the result type `T'`. It may be necessary to type-check `exp!` in analysis mode, though that could be inconvenient. -#### Bindings in `or`-Patterns +#### Bindings in `or`-Patterns ([#3807](https://github.com/dfinity/motoko/pull/3807)) When using `or`-patterns, it is possible to bind a variable in the alternatives. This is useful to avoid `case` repetitions: ``` @@ -621,7 +621,7 @@ Note: the obvious "solution", namely storing closure environments inside the ori #### Upgrades and Memory -The most difficult problem to solve in the programming model of the IC by far is the question of safe and robust upgrades. Motoko currently uses the IC's _stable memory_ API to serialise the entire heap of an actor into stable memory before an upgrade, and restore it afterwards. The crucial point of this is that the serialised format is fixed and not dependent on the compiler version. Consequently, it is perfectly fine if the new version of the actor has been compiled with a different (typically newer) compiler version that potentially uses a differen memory layout internally (e.g., a new garbage collector). +The most difficult problem to solve in the programming model of the IC by far is the question of safe and robust upgrades. Motoko currently uses the IC's _stable memory_ API to serialise the entire heap of an actor into stable memory before an upgrade, and restore it afterwards. The crucial point of this is that the serialised format is fixed and not dependent on the compiler version. Consequently, it is perfectly fine if the new version of the actor has been compiled with a different (typically newer) compiler version that potentially uses a different memory layout internally (e.g., a new garbage collector). The drawback is that this serialisation/deserialisation step is expensive. Worse, it may even run out of cycles.