Improvements covering a few ongoing issues

README.md

@@ -71,6 +71,11 @@ assert(record1.a === 1);
 assert(record1["a"] === 1);
 assert(record1 !== record2);
 assert(record2 === #{ a: 1, c: 3, b: 5 });
+assert(record1?.a === 1);
+assert(1 === record1?.a);
+assert(record1?.d === undefined);
+assert(record1?.d ?? 5 === 5);
+assert(3 === record1?.d ?? 3);
 ```
 
 #### `Tuple`
@@ -151,6 +156,14 @@ At runtime, attempting to create a `Record` with a key that is not a `string` or
 
 At runtime, it is a `TypeError` to add a value to a `Record` or `Tuple` of any type except the following: `Record`, `Tuple`, `string`, `number`, `symbol`, `boolean`, `bigint`, `undefined`, or `null`.
 
+However whenever the engine can figure out at parse time that something is wrong, it should fail at that moment:
+
+```js
+const r1 = #{ obj: {} }; // fails at parse time because an object declaration in a record is obviously going to be an error
+const r2 = #{ obj: true ? {} : #{} }; // will fail at runtime as it's not obvious from the parser's perspective that we should fail
+const r3 = #{ method() {} }; // fails at parse time
+```
+
 # Equality
 
 Instances of `Record` and `Tuple` are deeply immutable, so their equality works like that of other JS primitive value types like `boolean` and `string` instances:
@@ -326,6 +339,12 @@ JSON.stringify(#{ a: #[1, 2, 3] }); // '{"a":[1,2,3]}'
 JSON.stringify(#[true, #{ a: #[1, 2, 3] }]); // '[true,{"a":[1,2,3]}]'
 ```
 
+## JSON.parseImmutable
+
+We propose to add `JSON.parseImmutable` so we can extract a Record/Tuple type out of a JSON string instead of an Object/Array.
+
+The signature of `JSON.parseImmutable` is identical to `JSON.parse` with the only change being in the return type that is now a Record or a Tuple.
+
 ## `Record` prototype
 
 The `Record` prototype is an empty object.