1 References can be 'owned' or 'borrowed'.
2 They can also be 'shared' or 'exclusive'
3 And maybe I need 'const' as well??
5 Borrowed references need to be borrowed from somewhere, and it must be
7 - from a caller via function parameter passing
8 - from a data structure via a lookup function - if structure is
10 - from a lock - which asserts ownership while held
12 Owned references can be:
13 refcounted - are these borrowed from the refcount?
14 single - there is only ever one owner
15 The difference is that 'single' uses zero bits for the refcount.
16 So maybe if a structure has a field declared 'refcount' it is
17 refcounted, else it can only be 'single'.
19 A pointer is declared as
21 Attributes can appear afterwards
22 name: @type owned shared
24 ownership is transferred using
26 This nulls the variable or marks it invalid.
29 will create a new owned reference and is only permitted for refcounted
31 Owned references are dropped when they are replaced or go out of scope.
32 This results in a dec of refcount and possible a free - or "close" once
35 When a reference is borrowed I need to know where it is borrowed from.
36 The owner can be some other (complex) object or the call stack.
37 It might be some set of objects if we don't know for certain.
40 What are some difficult pointer usages that need clear understanding.
42 1/ linked lists and trees are easy. The link is owned.
43 2/ double-linked lists have two problems.
44 A/ The 'prev' link cannot be owned - so who is it borrowed from?
45 B/ The tail link back to the header.
47 The links aren't where the ownership resides. The ownership resides in
48 the total data structure - the list.
49 The list - represented by the head - owns the references to all members.
50 The pointers are just record keeping.
52 Pointers *can* store ownership, but they are just one option.
53 A function can declare that some ownership is stored or released
54 without the language being able to confirm it.
56 I need to write some code to explore what I want.
58 A ref is dereferenced with '@', but it can be left off if there is a field
59 reference, so "ref@.foo" and "ref.foo" are the same.
61 ref@new allocates a new object
62 ref@valid is true if the ref points to something
63 ref@drop drops the ref and invalidates the pointer ??
74 I wonder if I want user-defined reference attributes.
75 This would require generic support in the language.
76 The idea is that the language gurantees some simple properties
77 and the code provie the manipulations.
79 So the "owned" attribute is declared as 'single' meaning it isn't
80 copied with the pointer. However it can be explicitly copied
81 by a "get_ref" function which returns an 'owned' flag without consuming one.
83 Some attributes would be "sticky" meaning they follow a value around.
84 "mut" or "ro" would be like this.
85 Some fields in an object may only be accessed or changed by a method,
86 which may explicitly change flags.
87 "ro" might prevent updates, "mut" might permit them, "hidden" might
88 prevent all accesses, or "xray" might be needed to see anything.
90 Attributes could define trigger functions which are called in
91 certain circumstances.
92 "owned" might call free() when the value goes out of scope without being consumed.
94 Tracking the connection between "owned" and "borrowed" might be
95 tricky. I need some code to play with.