ocean-lang.org Git - ocean-D/blob - Numbers

   1
   2 How do numbers fit into an OO framework.
   3
   4 Number for which you can do
   5   a = b + c
   6   float = float + int
   7   a = i++
   8   a < b
   9
  10 There are several options:
  11
  12 A/  Number objects can be immutable
  13 B/  Number objects can be mutable and assignment makes a copy
  14 C/  Number objects can be mutable and assignment takes a reference.
  15
  16 If numbers are immutable, then what does
  17         i++
  18
  19 means?  It must mean that a new object is created which has a value
  20 one more than that value of the object stored in i, and this object is
  21 then stored in i.  So '++' operates on the name, not on the object.
  22 That seems a bit out of the spirit of oo where we operate on objects.
  23
  24
  25 If assignment makes a copy, then that is a problem for complex
  26 objects.  We absolutely need by-reference handling for many things.
  27 So we would some-how needs different assignment for different
  28 objects.  So take references, some take copies.  The difference would
  29 have to be explicit e.g.
  30     a = b  (reference)
  31     a := b (copy value)
  32
  33 that is error prone.
  34
  35
  36 If mutable objects assign by reference then
  37    a = b
  38    while (a++ < b+5)
  39         ;
  40 would never stop, so the model is unexpected and error prone.
  41
  42 So... where does that leave us?
  43
  44 It seems that operators:
  45    a + b
  46 should really create new objects.
  47 Operators like
  48     a += b
  49 Really must change the left-hand object
  50
  51 So assignments of number really really wants to be a value-copy.
  52 Maybe we use type tags to make it harder to go wrong.
  53 i.e.
  54    a := b
  55 Always makes 'a' a new object distinct from b.
  56    a =& b
  57 Always makes 'a' refer to the same object as b
  58    a = b
  59 is the same as =&, but is not allowed for 'bycopy' objects.
  60
  61 Hmm.. what sort of assignment happens to formal variables in a
  62 function call.  They should be by reference, but maybe changing the
  63 reference of a formal parameter shouldn't be permitted as that could
  64 lead to confusion?
  65
  66 or maybe......
  67
  68 Instead of two difference sorts of assignment, we could have
  69 auto-dereference objects.
  70 If a type is strict-once, the there is guaranteed never to be any
  71 aliasing. So in
  72    a = b + c
  73 the '+' creates a new object with sum of b and c and it is assigned by
  74 reference to a.  As there is no risk of an alias, no 'copy' is needed.
  75 But on
  76    a = b
  77 The object has a reference already, so to avoid counting the reference
  78 we make a new copy.
  79 So what happens in a function call where we want a by-reference
  80 parameter?
  81 We must be able to over-ride the auto-copy, but we still don't want
  82 reference counting.  So we need to know that one reference will
  83 outlive the other. In that case we use '&' to make a reference.
  84 For a function call, it is clear that the actual parameter reference
  85 lasts longer.
  86
  87 For a = &b
  88 we can probably use data-flow analysis to know when the object is
  89 destroyed.
  90 What about
  91     a[5] = &b;
  92     a[6] = &b;
  93     a[n] = 4;
  94
  95 Hmmmm..