X-Git-Url: https://ocean-lang.org/code/?p=ocean-D;a=blobdiff_plain;f=Ocean-types;h=a89544cc3c87da1b04b679ff0cff88bc5d401720;hp=c25bd1be7ca16f3a9b418f97e7d938b8917e36f7;hb=HEAD;hpb=5b97b38c643628f0845dbfcf050f0b382b2f7ac3 diff --git a/Ocean-types b/Ocean-types index c25bd1b..a89544c 100644 --- a/Ocean-types +++ b/Ocean-types @@ -146,7 +146,7 @@ What do I do with add subtract multiply divide index ---------- - I currently have an enum of types that is used to test compatability + I currently have an enum of types that is used to test comparability and for propagation. This needs to change .... I guess I need a struct type* What goes in it? - name @@ -167,6 +167,26 @@ What do I do with .Bool.true = a:char; b:char .Bool.false = ...... + I like "inheritance" but that doesn't allow the size of the whole to + be known in advance. + I need a way to talk about which instance is active, even if the value + isn't stored. So Pascal-like variant records are good. + Maybe a struct could be declared as 'extensible' and other structs + could 'extend', and it literally makes it bigger + struct a extensible {x1:int} + struct b extends a {y1:int} + struct c extends a extensible {y2:int} + struct d extends c {z1:int} + + now 'a' has room for x1, (y2 and z1) or y1 + Which is used depends on context .. or by assertion on content. + So extensions can set values for existing fields + struct z extends a {x1=4; string c} + + Syntax is a bit clumsy. Do I need "extensible"?? + + + Are enums just a fancy way of doing 'const'? I could have const: a=1; b=2; c; d @@ -278,3 +298,122 @@ Questions: 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 } + +-------------- +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.