Changes in / [ff1efc10:ad72c8b]
- Files:
-
- 2 edited
-
doc/proposals/vtable.md (modified) (13 diffs)
-
libcfa/src/Makefile.am (modified) (1 diff)
Legend:
- Unmodified
- Added
- Removed
-
doc/proposals/vtable.md
rff1efc10 rad72c8b 3 3 4 4 This is an adaptation of the earlier virtual proposal, updating it with new 5 ideas, re-framing it and laying out more design decisions. It should 6 eventually replace the earlier proposal, but not all features and syntax have 7 been converted to the new design. 5 ideas, reframing it and laying out more design decisions. 8 6 9 7 The basic concept of a virtual table (vtable) is the same here as in most 10 8 other languages. They will mostly contain function pointers although they 11 9 should be able to store anything that goes into a trait. 10 11 This should replace the virtual proposal, although all not all features have 12 been converted to the new design. 12 13 13 14 Trait Instances … … 38 39 combine(obj, 5); 39 40 40 As with `struct` (and `union` and `enum`), `trait` might be optional when41 using the trait as a type name. A trait may be used in assertion list as42 before.43 44 41 Internally a trait object is a pair of pointers. One to an underlying object 45 42 and the other to the vtable. All calls on an trait are implemented by looking … … 47 44 remaining arguments to it. 48 45 49 Trait objects can be moved by moving the pointers. Almost all other operations 50 require some functions to be implemented on the underlying type. Depending on 51 what is in the virtual table a trait type could be a dtype or otype. 46 Trait objects can be copied and moved by copying and moving the pointers. 47 They should also be able to own or borrow the underlying object. 52 48 53 49 Hierarchy … … 60 56 tree. 61 57 62 The hiera rchy would be a tree of types, of traits and structs. Currently we do58 The hierachy would be a tree of types, of traits and structs. Currently we do 63 59 not support structural extension, so traits form the internal nodes and 64 60 structures the leaf nodes. … … 66 62 The syntax is undecided but it will include a clause like `virtual (PARENT)` 67 63 on trait and struct definitions. It marks out all types in a hierarchy. 68 PARENT may be omitted, if it is this type is the root of a hiera rchy. Otherwise64 PARENT may be omitted, if it is this type is the root of a hierachy. Otherwise 69 65 it is the name of the type that is this type's parent in the hierarchy. 70 66 … … 77 73 from a parent type to a child type are conditional, they check to make sure 78 74 the underlying instance is an instance of the child type, or an instance of 79 one of its children. The type then is recoverable at run -time.75 one of its children. The type then is recoverable at runtime. 80 76 81 77 As with regular trait objects, calling a function on a trait object will cause 82 a look -up on the the virtual table. The casting rules make sure anything that78 a lookup on the the virtual table. The casting rules make sure anything that 83 79 can be cast to a trait type will have all the function implementations for 84 80 that trait. 85 81 86 Converting from a concrete type (structures at the edge of the hier archy) to82 Converting from a concrete type (structures at the edge of the hierchy) to 87 83 an abstract type works the same as with normal trait objects, the underlying 88 object is packaged with a virt ual table pointer. Converting back to an abstract84 object is packaged with a virtal table pointer. Converting back to an abstract 89 85 type requires confirming the underlying type matches, but then simply extracts 90 86 the pointer to it. … … 96 92 it is the trait object could be a single pointer. 97 93 98 It is triv ial to do if the field with the virtual table pointer is fixed.94 It is trival to do if the field with the virtual table pointer is fixed. 99 95 Otherwise some trickery with pointing to the field and storing the offset in 100 96 the virtual table to recover the main object would have to be used. … … 118 114 119 115 The main thing CFA would need to do it this way is some single point where 120 the type declaration, including the functions that sati sfy the trait, are116 the type declaration, including the functions that satify the trait, are 121 117 all defined. Currently there are many points where this can happen, not all 122 118 of them will have the same definitions and no way to select one over the … … 126 122 time and a single vtable created for each type at compilation time. 127 123 128 ### Explic itResolution Points:129 Slightly looser than the above, there are explic itpoints where the vtables124 ### Explicate Resolution Points: 125 Slightly looser than the above, there are explicate points where the vtables 130 126 are resolved, but there is no limit on the number of resolution points that 131 127 might be provided. Each time a object is bound to a trait, one of the 132 resolutions is selected. This might be the most flex ible option.128 resolutions is selected. This might be the most flexable option. 133 129 134 130 An syntax would have to be provided as above. There may also be the option 135 131 to name resolution points so that you can choose between them. This also 136 could come with the ab ility to forward declare them.132 could come with the ablity to forward declare them. 137 133 138 134 Especially if they are not named, these resolution points should be able to … … 145 141 its own resolution. Syntax-wise this is the simplest as it should be able 146 142 to use just the existing declarations and the conversion to trait object. 147 It also is very close to the current polymorphic re solution rules.143 It also is very close to the current polymorphic reolution rules. 148 144 149 This works as the explic itresolution points except the resolution points150 are implic itand their would be no selection of which resolution to use. The145 This works as the explicate resolution points except the resolution points 146 are implicate and their would be no selection of which resolution to use. The 151 147 closest (current) resolution is always selected. 152 148 153 This could easily lead to an explosi on of vtables as it has the most fine149 This could easily lead to an explosition of vtables as it has the most fine 154 150 grained resolution the number of bindings in a single scope (that produces 155 151 the same binding) could be quite high. Merging identical vtables might help … … 160 156 161 157 Vtables interact badly with the thunk issue. Conceptually vtables are static 162 like type/function data they carry, as those deci sions are made by the158 like type/function data they carry, as those decitions are made by the 163 159 resolver at compile time. 164 160 165 161 Stack allocated functions interact badly with this because they are not 166 static. There are se veral ways to try to resolve this, however without a162 static. There are serveral ways to try to resolve this, however without a 167 163 general solution most can only buy time. 168 164 … … 172 168 173 169 Dynamically allocated vtables introduces memory management overhead and 174 requires some way to different iate between dynamic and statically allocated170 requires some way to differentate between dynamic and statically allocated 175 171 tables. The stale function pointer problem continues unless those becomes 176 172 dynamically allocated as well which gives us the same costs again. … … 179 175 is now the limiting factor but it should be effectively the same as the 180 176 shortest lifetime of a function assigned to it. However this still limits the 181 lifetime "implic itly" and returns to the original problem with thunks.177 lifetime "implicately" and returns to the original problem with thunks. -
libcfa/src/Makefile.am
rff1efc10 rad72c8b 71 71 ) 72 72 73 -include $(libdeps) 73 include $(libdeps) 74 75 $(libdeps): 76 @mkdir -p $(dir $@) 77 @echo '#dummy' > $@ 74 78 75 79 prelude.o : prelude.cfa extras.cf gcc-builtins.cf builtins.cf @CFACC@ @CFACPP@
Note:
See TracChangeset
for help on using the changeset viewer.
