1 # This is a living document - delete things when done. Avoid discussion.
3 ## Needs implementations
5 ### Current version (Cataract Creek)
7 - reference to struct or intrinsic (@foo), with @new, @free, @nil and ? to test
8 - allow passing objects to functions by reference is requested
9 - add [] as size-of-array
10 - replace [foo::] declaration of array with [] - fix all main() calls
11 - ensure all param passing and value return is handled correctly
12 - revise all commentary
16 ### Next Version (Govetts Creek)
17 - int nat cyc {i,n,c}{8,16,32,64} - maybe not cyc - it needs size.
18 - ops: # & | ~ &~ - no shift: use (N * #shift) or (N / #shift)
20 - make '.' modifier interpolate a deref if needed
21 - enum, with multi-valued names. enum foo { yes, no, many(10) }
22 bar:foo=.yes; if bar == .no... if ?bar.many: print bar.many, "items"
23 Maybe .true and .false for Boolean
24 - change use/case labels in ".name" which creates a local enum if no
26 - set, with bool or int members. set foo { pinned, memalloc, priority(4) }
27 bar:foo = .memalloc | .priority(2). if bar.pinned: bar.priority += 1
28 . array slices - references to arrays "foo: []bar"
29 - array access to read bytes from strings. How to get length? "?string[4]" ??
31 - revise all commentary
35 ### Subsequent version
36 - 'return' statement similar to 'use', but only valid a function context
37 - 'return' can take no value when function has inline/transparent return value
38 - simple methods. Define "func type.name...." and the name will only be visible
39 within namespace for type.
40 - optional args for functions - if value given
41 - named args? Needs to look like manifest structs
42 - array args - last parameter can collect all remaining as array if attribute 'open'
43 do I need attribute? Can anything be type compatible with both X and []X ??
44 - initial values for return parameters
45 - convert between string and array-of-cyc8
47 - transparent fields, parameters which are structs or pointers
48 - transparent fields which are arrays
49 - transparent results from functions to have same effect as inline-results
50 - manifest values for records: [.foo = a, .bar = b]
51 - manifest values for arrays: [expr = expr, ...]
52 - constant structure definitions
53 - const structures can inherit from another, and update select fields.
54 - 'use' labels *must* appear in case statements.
55 - 'then' can extend a case section into some other.
58 - a suffix on a number/string can provide soft typing which is interpreted
59 in type context. Must like .enumvalue is interpreted only the context of
60 expected type, '43i' would only be meaningful in the same context.
61 - const arrays that are initialized incrementally throughout the code,
62 and post-processed at compile-time, e.g. to sort or derive LR tables.
63 Maybe even across modules.
65 Maybe 'const' can be followed by name of a const which forms the namespace.
66 So a struct bar containing x and y could be initialized
69 Then an array could be extended with [+]
73 The syntax needs to be clearly different from
75 if that is still allowed
76 Maybe the '=' is enough to differentiate
78 - IN and OUT should not be completely ignored when not expected.
79 As well as causing NEWLINE to be ignored, there should be some
80 balance requirement. Some productions should be required to be
81 balanced. Lists should not have gratuitous indents.
82 Revisit everything I considered before, but now consider it only
84 - union types - how do I want to support these? inheritance with variance?
86 - 'error' value for various types. NIL for pointer NaN for float, extra flag bit
87 for integers. -MAX_INT ??
88 - enum as array index. foo:[:enum]int. foo[.baz] = 23
90 - const fields in structs: like const, but in 'type' namespace, not 'module'
91 - 'borrowed' and 'owned' attributes for pointers. .free method
92 - interfaces - list of methods that must be defined
93 - standard interfaces to access operations: group, field, binary, logical
94 - modules - exported names in versions, and import lists
95 on types, fields, constants, etc
96 - foreach variable-list := make_generator() do
97 A generator has 'first', 'next' and 'finally' methods
98 'first' and 'next' return the same type which is conditional ('?' works)
99 'finally' returns some other type - possibly Tnone - which goes to
100 a set of case at end of loop
102 - attributes for fields and local variables
103 transparent - names inside can be accessed directly
105 handled - accesses convert to function calls??
106 constant - compile time constant - not stored
108 add-only - ?? like append-only.
109 read-only - set early never changed?
111 owned - Can be borrowed and freed
112 borrowed - There is somewhere this is borrowed from
114 pure - definitely not an error
115 endian(big,small,pdp)
116 attributes for whole struct
117 unsorted - fields appear as written
118 packed - like unsorted, but no gaps permitted.
120 - lambda functions for passing as arg to function.
121 Are these always there to provide an interface for a value?
122 Do I want a syntax for functions that just provides a value
123 func (a:number; b:string):number = a+b[]
126 - iso suffixes for number?
127 - static variables. Easy to implement, but need a syntax. Something
131 reference attributes for locks and refcounts etc
133 - do/go/run/fork/async complex statement
134 All local variables accessed in the body are read-only
135 and copied to a new frame, and code is run in a new thread.
136 Thread is mostly invisible. It interacts through shared objects,
137 particularly the caller might create a channel and the thread
138 might send messages on it. Any interesting handshakes
139 are mediated by appropriate data structures.
141 - arbitrary value asserts tied to variable attributes.
142 e.g. ranges for value and relationships between fields
143 These are tested by compiler at any changed. Somehow.
145 - expose parse info for editing by code run at compile time.
146 This allows new attributes to be implemented in app code.
147 E.g. handling bigendian fields by adding conversion functions.
149 - Finalize what a "main" program looks like.
150 should argv come from a library (sys.argv), or should environ go to main?
153 - constructors and destructors - or "after" ??
154 destructors, which can be declared inline
155 - vtables, fat pointers, list of approaches
156 - interfaces, inheritance
157 - closures, threads, co-routines, generators lamdas
158 - generics/templates. These should be just a compile-time
159 decision. Same code can be called with suitable methods passed, or
160 recompiled in the new context and then optimised.
161 - introspection / reflection ?
162 e.g. support serialization
163 find function given a string holding the name
164 measure coverage, adjust based on performance metrics
165 auto-create mock objects
166 Is this just parsing the details in the obj file?
168 - parameterised types, and dependant types
169 - message passing primitives
170 - overloading for numbers
172 - ensure list_head type concept can work
174 NO - pattern matching for destructuring??
175 - casts to and from "binary".
177 - ??? algebraic types
180 - augmented and overloaded pointers
181 An augmented pointer can also store a flag- for a bitlock etc
182 An overloaded pointer can alternately store an int - e.g. error code
183 - garbage collection?
184 - UTF8 string disection
186 - cvt() interface an format() function
187 - parsing: rexep? LALR? sscan?
189 - auto-growing buffer including strings