(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
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
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 }
code / ocean-D / blobdiff