X-Git-Url: https://ocean-lang.org/code/?p=ocean-D;a=blobdiff_plain;f=Ocean-types;h=ed57f26d1407bee3baa002089d14bec3b85688fb;hp=16714803a186af0502d3c45205a47aec6e4501ab;hb=6830d7faa83def1431a9f5a981c008eeb272a5f6;hpb=da2b05008783a3fa1c92f546e237703237129c71

diff --git a/Ocean-types b/Ocean-types
index 1671480..ed57f26 100644
--- a/Ocean-types
+++ b/Ocean-types
@@ -304,3 +304,96 @@ I'm in the middle of stage-1 on structures.
 
 I need a type to parse the declaration into.  It needs to be a linked list
 of fields, each of which is a type, a name, and an initial value.  i.e. a 'struct field'.
+
+-----------------
+
+Numbers...
+I want signed/unsigned/bitset integers (and probably floats).
+These are different sizes, and I want to move 'type' out of 'value'
+so I can have arrays of numbers that are *just* the densely packets numbers.
+
+So there are two questions here: how will I handle values in oceani, and
+what are the semantics of numbers in ocean.
+
+I think I want bitops to requires bitsets and arith ops to require signed/unsigned.
+But there is some overlap.
+e.g. we use bitops to test if a number is a power of two
+We sometimes use bitops to multiply, but that is probably best avoided.
+use * to multiply.
+
+Converting between the two can be done with simple assignment.
+
+So + - * / %     require/assume signed or unsigned
+   | & ~ << >>   require/assume bitset
+
+  #  accepts either and produces a bitset
+
+Other issue is overflow/underflow checking.
+Do we need another unsigned type - cyclic
+
+    i32 - signed integer in 32 bits
+    u32 - unsigned integer
+    c32 - unsigned with overflow permitted and ignored
+    b32 - bitset
+
+    int uint cint bset - whatever size.
+
+i32 and u32 detect overflow/underflow and set to NaN - all 1's
+If I want to allow overloading (such a NaN), I need a type that
+declare no overloading. s32 and c32?  Or annotations.  !s32 !u32
+
+So what about values in oceani?  I want to separate out the type and not
+use a union.
+Where are they used?
+ - return of init, prepare, parse, dup
+ - passed to  print, cmp, dup, free, to_int, to_float, to_mpq
+ - field in 'struct variable'
+ - field in 'struct lrval'
+ - result of 'interp'
+ - intermediate left/right in interp
+ - field in array and struct field
+ - field in 'struct val' for manifest constants
+
+So:
+  variable gets a 'type' pointer and a union which can be a pointer
+  to the value, or the value itself (depending on size)
+  lrval get a type pointer as well, plus the union
+  interp returns ...
+
+
+-----------------
+Struct/array initialisers.
+I like [a,b,c] rather than {a,b,c} because the latter can look like code.
+But [] is also array indexing.
+So an array initializer could look:
+  [ [1] = "hello", [5] = "there" ]
+and that is confusingly similar to nested initialization
+  [ [1,2] , [3,4] ]
+Options:
+ 1/ use different outer.  {}  () <> << >>
+   < is possibly as it is not a prefix operator.
+     But nesting results in <<1,2>,<3,4>> which looks like << instead of < <
+   {} I already don't like
+   () is bad enough with function calls - it is best if it is grouping only.
+     though with function calls it is a list ...
+   << [1]="hello", [2]="there" >>...  I don't really like that
+
+   array[ ]
+   struct[ ]
+     No, too noisy.
+
+ 2/ use different inner syntax.
+     [ .[1] = "hello", .[5] = "hello" ]
+
+ What about a newline-based syntax:
+  a: [4]int :
+	[0] = 2
+	[1] = 3
+	[3] = 1
+
+ Nice, but doesn't actually help.  Still need .[] because I want to allow
+ a one-line syntax too.
+ Maybe I just use {} after all.
+
+  a:[4]int = { [0]=2, [1]=3, [3]=1 }
+ Yes, I guess that is best.