ocean-lang.org Git - ocean-D/blob - Ocean-references

   1 References can be 'owned' or 'borrowed'.
   2 They can also be 'shared' or 'exclusive'
   3 And maybe I need 'const' as well??
   4
   5 Borrowed references need to be borrowed from somewhere, and it must be
   6 clear where.
   7 - from a caller via function parameter passing
   8 - from a data structure via a lookup function - if structure is
   9   append-only
  10 - from a lock - which asserts ownership while held
  11
  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'.
  18
  19 A pointer is declared as
  20     name: @type
  21 Attributes can appear afterwards
  22     name: @type owned shared
  23
  24 ownership is transferred using
  25      new := *old (??)
  26 This nulls the variable or marks it invalid.
  27 An assignment like
  28      new : @type = old
  29 will create a new owned reference and is only permitted for refcounted
  30
  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
  33 I have objects.
  34
  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.
  38
  39
  40 What are some difficult pointer usages that need clear understanding.
  41
  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.
  46
  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.
  51
  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.
  55
  56 I need to write some code to explore what I want.
  57
  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.
  60
  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 ??
  64
  65 Maybe
  66     foo:@type = @new()
  67     foo = @null
  68
  69     foo?
  70
  71
  72
  73 ----
  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.
  78
  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.
  82
  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.
  89
  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.
  93
  94 Tracking the connection between "owned" and "borrowed" might be
  95 tricky.  I need some code to play with.