diff options
| -rw-r--r-- | notes/error_handling.txt | 25 | ||||
| -rw-r--r-- | notes/map_api.txt | 57 | ||||
| -rw-r--r-- | notes/misc_syntax.txt | 16 | ||||
| -rw-r--r-- | notes/qualifiers.txt | 40 |
4 files changed, 138 insertions, 0 deletions
diff --git a/notes/error_handling.txt b/notes/error_handling.txt index 9feeb64..9848e57 100644 --- a/notes/error_handling.txt +++ b/notes/error_handling.txt @@ -108,3 +108,28 @@ Perhaps it could all be enums, and then `None` could be: # NoneEnum.slul only None + +Granularity of error handling +----------------------------- + +Example: + + try + do_stuff x.get_item y.get_item + catch SomeError e + ... + +What if both do_stuff and get_item can fail? +Also, from the reading the code, it's not clear what can fail. + +The latter problem could be solved by requiring everything that can fail +to return an optional value: + + # if any of the get_item calls would fail, then the "do_stuff" + # call expression would also evaluate to None (without calling "do_stuff") + # (BUT... this is not obvious from this syntax!) + if not do_stuff x.get_item? y.get_item? + ... + + # or + if not (do_stuff x.get_item? y.get_item?)? diff --git a/notes/map_api.txt b/notes/map_api.txt index 3a45d39..cfdbeec 100644 --- a/notes/map_api.txt +++ b/notes/map_api.txt @@ -83,3 +83,60 @@ Definitions: return ?V value end + +Get-or-insert API +----------------- + +In some cases, computing the "default value" may have side effects (or might +just be expensive). + + PendingEntry pending = map.point_to_key "SomeKey" + if pending.exists + pending.set_value (pending.get_value + 1) + else + pending.set_value compute_value + +There are a few problems: + +1. How to make the API intuitive? The names should be inuitive. + + func name: + point_to_key + at_key + at_location + lookup_pending + type name: + PendingEntry + EntryReference + EntryRef + EntryPointer + +2. How to avoid allocations. + + - This is a common problem and should be solved in a common way. + - Maybe some "maxsize N" attribute for objects that have the size + of at most N references or integers (whichever is greater). + Then the objects can be stack-allocated (or even returned + in registers!) + - But how should this work with interfaces? + +3. How to handle race conditions + + - Using multiple PendingEntry's on the same map should not cause + incorrect behavior. It could: + - Trigger a compile-time error + - Trigger an immediate runtime error + - Trigger a delayed runtime error + - It could handle the race condition correctly. + - Or the API could be designed so the Map has the PendingEntry stuff + built-in: + map.navigate_to "SomeKey" # -> typestated Navigated + map.navigated_exists # typestate Navigated -> NavigatedExists + map.navigated_set + map.navigated_get # must be in typestate NavigatedExists + map.navigation_finished # -> typestate Normal + - Perhaps it could use typestates. + - And the normal state could be a "final" state, + so calling map.finish_navigation would be required. + - It would be nice if the caller could provide storage + (how to do this in a safe way?) diff --git a/notes/misc_syntax.txt b/notes/misc_syntax.txt index de47d5d..feabf22 100644 --- a/notes/misc_syntax.txt +++ b/notes/misc_syntax.txt @@ -113,3 +113,19 @@ And perhaps forbid mixing `not` and comparison operators? not a == b # error # and perhaps also: f a or b + +Perhaps require a . on all calls? +This would make method and function syntax more similar: + + .do_stuff + obj.do_stuff + + # Or just use parentheses + do_stuff() + obj.do_stuff() + + # Or `->` for functions and `.` for fields? + ->do_stuff + obj->do_stuff + localvar = 123 + obj.field = 123 diff --git a/notes/qualifiers.txt b/notes/qualifiers.txt index 0e358e7..5cb8145 100644 --- a/notes/qualifiers.txt +++ b/notes/qualifiers.txt @@ -1,6 +1,46 @@ Qualifiers ========== +Which qualifiers are needed? +---------------------------- + + modifiable + aliased (= can be modified through other reference(s)) + keep (= reference might be kept beyond function/struct lifetime) + +Pros with keywords as qualifiers: + +* Intuitive + +Cons with keywords as qualifiers: + +* Verbose +* In parametric types, it's unintuitive which type they apply to: + + List aliased SomeObject + +Which symbols could be used? + + SomeObject! # modifiable (already implemented) + SomeObject@ # i/o + SomeObject% # aliased/shared + SomeObject$ # aliased/shared + SomeObject^ # aliased/shared + SomeObject+ # aliased/shared + SomeObject& # aliased/shared + SomeObject* # keep + SomeObject~ # keep + SomeObject^ # keep + SomeObject+ # keep + +Best option? + + SomeObject! # modifiable (already implemented) + SomeObject@ # i/o + SomeObject% # aliased/shared + SomeObject+ # keep + + Transitive qualifiers --------------------- |