updates

[ocean-D] / Ocean-references

diff --git a/Ocean-references b/Ocean-references
new file mode 100644 (file)
index 0000000..42391e2
--- /dev/null
+++ b/Ocean-references
@@ -0,0 +1,95 @@
+References can be 'owned' or 'borrowed'.
+They can also be 'shared' or 'exclusive'
+And maybe I need 'const' as well??
+
+Borrowed references need to be borrowed from somewhere, and it must be
+clear where.
+- from a caller via function parameter passing
+- from a data structure via a lookup function - if structure is
+  append-only
+- from a lock - which asserts ownership while held
+
+Owned references can be:
+  refcounted - are these borrowed from the refcount?
+  single - there is only ever one owner
+The difference is that 'single' uses zero bits for the refcount.
+So maybe if a structure has a field declared 'refcount' it is 
+refcounted, else it can only be 'single'.
+
+A pointer is declared as
+    name: @type
+Attributes can appear afterwards
+    name: @type owned shared
+
+ownership is transferred using
+     new := *old (??)
+This nulls the variable or marks it invalid.
+An assignment like
+     new : @type = old
+will create a new owned reference and is only permitted for refcounted
+
+Owned references are dropped when they are replaced or go out of scope.
+This results in a dec of refcount and possible a free - or "close" once
+I have objects.
+
+When a reference is borrowed I need to know where it is borrowed from.
+The owner can be some other (complex) object or the call stack.
+It might be some set of objects if we don't know for certain.
+
+
+What are some difficult pointer usages that need clear understanding.
+
+1/ linked lists and trees are easy.  The link is owned.
+2/ double-linked lists have two problems.
+  A/ The 'prev' link cannot be owned - so who is it borrowed from?
+  B/ The tail link back to the header.
+
+The links aren't where the ownership resides.  The ownership resides in
+the total data structure - the list.
+The list - represented by the head - owns the references to all members.
+The pointers are just record keeping.
+
+Pointers *can* store ownership, but they are just one option.
+A function can declare that some ownership is stored or released
+without the language being able to confirm it.
+
+I need to write some code to explore what I want.
+
+A ref is dereferenced with '@', but it can be left off if there is a field
+reference, so "ref@.foo" and "ref.foo" are the same.
+
+ref@new allocates a new object
+ref@valid is true if the ref points to something
+ref@drop drops the ref and invalidates the pointer ??
+
+Maybe
+    foo:@type = @new()
+    foo = @null
+
+    foo?
+
+
+
+----
+I wonder if I want user-defined reference attributes.
+This would require generic support in the language.
+The idea is that the language gurantees some simple properties
+and the code provie the manipulations.
+
+So the "owned" attribute is declared as 'single' meaning it isn't
+copied with the pointer.  However it can be explicitly copied
+by a "get_ref" function which returns an 'owned' flag without consuming one.
+
+Some attributes would be "sticky" meaning they follow a value around.
+"mut" or "ro" would be like this.
+Some fields in an object may only be accessed or changed by a method,
+which may explicitly change flags.
+"ro" might prevent updates, "mut" might permit them, "hidden" might
+prevent all accesses, or "xray" might be needed to see anything.
+
+Attributes could define trigger functions which are called in
+certain circumstances.
+"owned" might call free() when the value goes out of scope without being consumed.
+
+Tracking the connection between "owned" and "borrowed" might be
+tricky.  I need some code to play with.