X-Git-Url: https://ocean-lang.org/code/?p=ocean-D;a=blobdiff_plain;f=Ocean-types;h=4aa4e8976565620b460e5440a0580297d57d1173;hp=f0f9d929494acf7ae114e17776f33d09710154cb;hb=83f7f2eae2f646ef67bb024ec50d1a3a4443de04;hpb=6bbab56e5001bac144c6ef8fe73ae27df4695bb3

diff --git a/Ocean-types b/Ocean-types
index f0f9d92..4aa4e89 100644
--- a/Ocean-types
+++ b/Ocean-types
@@ -24,6 +24,19 @@ Types can be constructed with
    (args:: args)  procedure type
    (args:: type)    function type
 
+  I think that for pointer/array constructor, the decoration comes first.
+    foo: [5]int
+  is an array of 5 integers, so foo[5] is an int
+    foo: @bar
+  is an owned pointer to bar, so "foo@" is a bar.
+    foo: @[5]int
+  is an owner pointer to 5 integers while
+    foo:[5]^int
+  is an array of 5 borrowed pointers to integers.
+  Having the result type at the end fits better with the function type.
+   foo:(int, int)string
+  then foo(1,2) returns a string.
+
 
 The content of struct and record are a list of:
    fieldname: type
@@ -94,9 +107,43 @@ Plan:
      I think I need to disassociate the type from the storage.
      So a 'value' is a parsed constant, but something new is needed for
      the content of a variable.
+     Also, something new is needed for an intermediate lvalue such as an
+     index to an array or a field in a record.  Ths is a type plus a pointer.
+     What about rvalues and the result of a calculation.  I guess I store
+     that in a temp location, with a pointer...
+
+     I need to be clear what "interp_exec()" returns.  Conceptually it
+     can be an object of any type, and for procedures it can be a tuple of
+     objects.  It needs to identify a type and a value of that type.
+     The "value" might be a reference into a variable, or it might be
+     a copy from a calculation.  Eventually the reference will have
+     ownership information
   const
   struct
 
+
+Steps:
+ 0/ when does 1/2 produce an integer?  Only when explicitly expected.
+ 1/ remove 'tail' from value
+ 2/ define a 'type'.
+ 3/ Add a 'Vtyped' vtype and a 'type' pointer
+ 4/ add an owership enum: borrowed, single
+ 3/ add a 'void *valref' ??
+ 4/ Convert num bool str label to Vtyped
+
+No, this is awkward because propagate_types wants a 'type' and this intermediate
+format has a enum+pointer.  So make it just a pointer...
+What do I do with
+  Vnolabel - rule flag
+  Vunknown   - NULL pointer
+  Vnone  - special value
+
+
+ A 'type' must be able to:
+  check is it can convert to some other type, reporting if it wants to
+  convert to another type.  This requires visibility into other types.
+  print, compare, parse
+  add subtract multiply divide index
 ----------
 
  I currently have an enum of types that is used to test compatability
@@ -142,3 +189,112 @@ Plan:
 
  allocating isn't really a top priority, so I should just focus on
  non-allocated types.
+
+
+-----
+I need a list of steps again:
+
+ - look up type by name and add syntax for
+      name : type = value
+   and
+      name : type
+
+ - Add arrays:
+      name : type[size]
+        e.g. int[4] or foo@[3]
+          What is int[5][20] ?? it is an array of int[5], which is backwards.
+          So maybe I want [5][20]int ??
+    declares an array of that type/size
+      name : [] = [ 1,2,3 ]
+    declares an array of 3 numbers.
+      name[1]
+    extracts an element from the array,
+      name[2] = 4
+    updates an element
+      name[4:5]
+    creates a slice, which can be stored in a var (borrowed ref) or
+    assigned to
+
+    This requires:
+     - new type class which has a size and member type
+     - new type access methods: index and size(?)
+     - new syntax
+     - new manifest values: [a,b,c] creates an array of whatever member type.
+
+ - add syntax for
+      struct name : [[ name : type ]]
+   to define a new struct
+
+ - add syntax to extra a field from a struct
+        how is this type-checked if I don't know the type yet?
+
+ - add syntax for pointers
+     a:= new(struct foo)
+     a:struct foo^ = new()
+
+-------
+Questions:
+  If I declare "struct foo ..." do I use "foo" or "struct foo" to ref the type?
+  I think just "foo".
+  So structs, records, enums, and classes must have distinct names.
+
+ When do I differentiate between compile-time constants and run-time values?
+ When declaring an array, do I require the size to be constant?
+ In a struct I do ... at time of declaration I calculate the size.
+ For foo:[sqr(a)]int
+ I do that too - and it is at run-time.
+ So during parsing, I need to describe the array with a member-type and executable size.
+ When that is evaluated, a type is created.
+ So we really need an executable which returns a type.
+ But ... we need to know the type when doing type analysis.  So while variable size
+ is OK, the compiler needs to know what it is.  Maybe the size needs to be a constant, as in
+ a names assiged with "size ::= 4*5".  This gives the compiler some chance of comparing
+ types of array - and doing range checking on indexes.
+
+ We currently call var_init to set the type of a variable during type
+ analysis - which makes sense.
+ But for an array we don't have the final type until run-time.  So we need an
+ intermediate type.
+ So (for now) the size of an array is either a NUMBER or an IDENTIFIER which must be a
+  constant var.
+ I need a point where the type is instantiated - where the variable is evaluated
+  and the size is set.  I guess this happens when the 'struct var' is evaluated...
+  no, when a Declare binode is evaluated.
+
+ What happens if I have
+    a:[foo]number = thing
+ I guess the type analysis needs to afirm that thing has the correct type,
+ then a doesn't need to be initialized.
+
+ If I find
+    a[4] = "hello"
+ and 'a' hasn't been declared .... obviously an error.
+
+ When/what/how.
+  For field access, I need to know the type of the variable.
+  But I can delay the look up until type analysis.
+  So a[4] is Index(a, 4) - a binode
+     a.foo is Field(a, "foo") -  need a new exec type - Fieldname
+     a(args) is Call(a, args) - need a new Binode type - Tuple.
+
+So I have to delay 'const' assessment to later too.
+
+----------
+Where do type definition go?
+I don't think they go with statements, they belong separately.
+I don't want the full separation of a "type" section like Pascal
+So they probably go at the top level, equivalent to "program" - and before.
+They start with "struct" or "enum" or "record" etc.
+
+So: what about constants?  These are currently statements and so affect a scope in time.
+But for declaring arrays in structs, or initial values of fields, we might want constants.
+A constant could be within a struct, but only that it too limiting.  I need module-wide
+constants.
+So I guess:
+
+   const:
+      name ::= value
+      name ::= value
+
+or
+   const { name ::= value ; name ::= value }