Changeset 1b94115


Ignore:
Timestamp:
Dec 13, 2018, 2:59:13 PM (5 years ago)
Author:
Andrew Beach <ajbeach@…>
Branches:
ADT, aaron-thesis, arm-eh, ast-experimental, cleanup-dtors, deferred_resn, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, no_list, persistent-indexer, pthread-emulation, qualifiedEnum
Children:
ff1efc10
Parents:
0765121
Message:

The vtable proposal has been updated from the early feedback.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/proposals/vtable.md

    r0765121 r1b94115  
    33
    44This is an adaptation of the earlier virtual proposal, updating it with new
    5 ideas, reframing it and laying out more design decisions.
     5ideas, re-framing it and laying out more design decisions. It should
     6eventually replace the earlier proposal, but not all features and syntax have
     7been converted to the new design.
    68
    79The basic concept of a virtual table (vtable) is the same here as in most
    810other languages. They will mostly contain function pointers although they
    911should 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.
    1312
    1413Trait Instances
     
    3938        combine(obj, 5);
    4039
     40As with `struct` (and `union` and `enum`), `trait` might be optional when
     41using the trait as a type name. A trait may be used in assertion list as
     42before.
     43
    4144Internally a trait object is a pair of pointers. One to an underlying object
    4245and the other to the vtable. All calls on an trait are implemented by looking
     
    4447remaining arguments to it.
    4548
    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.
     49Trait objects can be moved by moving the pointers. Almost all other operations
     50require some functions to be implemented on the underlying type. Depending on
     51what is in the virtual table a trait type could be a dtype or otype.
    4852
    4953Hierarchy
     
    5660tree.
    5761
    58 The hierachy would be a tree of types, of traits and structs. Currently we do
     62The hierarchy would be a tree of types, of traits and structs. Currently we do
    5963not support structural extension, so traits form the internal nodes and
    6064structures the leaf nodes.
     
    6266The syntax is undecided but it will include a clause like `virtual (PARENT)`
    6367on trait and struct definitions. It marks out all types in a hierarchy.
    64 PARENT may be omitted, if it is this type is the root of a hierachy. Otherwise
     68PARENT may be omitted, if it is this type is the root of a hierarchy. Otherwise
    6569it is the name of the type that is this type's parent in the hierarchy.
    6670
     
    7377from a parent type to a child type are conditional, they check to make sure
    7478the underlying instance is an instance of the child type, or an instance of
    75 one of its children. The type then is recoverable at runtime.
     79one of its children. The type then is recoverable at run-time.
    7680
    7781As with regular trait objects, calling a function on a trait object will cause
    78 a lookup on the the virtual table. The casting rules make sure anything that
     82a look-up on the the virtual table. The casting rules make sure anything that
    7983can be cast to a trait type will have all the function implementations for
    8084that trait.
    8185
    82 Converting from a concrete type (structures at the edge of the hierchy) to
     86Converting from a concrete type (structures at the edge of the hierarchy) to
    8387an abstract type works the same as with normal trait objects, the underlying
    84 object is packaged with a virtal table pointer. Converting back to an abstract
     88object is packaged with a virtual table pointer. Converting back to an abstract
    8589type requires confirming the underlying type matches, but then simply extracts
    8690the pointer to it.
     
    9296it is the trait object could be a single pointer.
    9397
    94 It is trival to do if the field with the virtual table pointer is fixed.
     98It is trivial to do if the field with the virtual table pointer is fixed.
    9599Otherwise some trickery with pointing to the field and storing the offset in
    96100the virtual table to recover the main object would have to be used.
     
    114118
    115119The main thing CFA would need to do it this way is some single point where
    116 the type declaration, including the functions that satify the trait, are
     120the type declaration, including the functions that satisfy the trait, are
    117121all defined. Currently there are many points where this can happen, not all
    118122of them will have the same definitions and no way to select one over the
     
    122126time and a single vtable created for each type at compilation time.
    123127
    124 ### Explicate Resolution Points:
    125 Slightly looser than the above, there are explicate points where the vtables
     128### Explicit Resolution Points:
     129Slightly looser than the above, there are explicit points where the vtables
    126130are resolved, but there is no limit on the number of resolution points that
    127131might be provided. Each time a object is bound to a trait, one of the
    128 resolutions is selected. This might be the most flexable option.
     132resolutions is selected. This might be the most flexible option.
    129133
    130134An syntax would have to be provided as above. There may also be the option
    131135to name resolution points so that you can choose between them. This also
    132 could come with the ablity to forward declare them.
     136could come with the ability to forward declare them.
    133137
    134138Especially if they are not named, these resolution points should be able to
     
    141145its own resolution. Syntax-wise this is the simplest as it should be able
    142146to use just the existing declarations and the conversion to trait object.
    143 It also is very close to the current polymorphic reolution rules.
     147It also is very close to the current polymorphic resolution rules.
    144148
    145 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
     149This works as the explicit resolution points except the resolution points
     150are implicit and their would be no selection of which resolution to use. The
    147151closest (current) resolution is always selected.
    148152
    149 This could easily lead to an explosition of vtables as it has the most fine
     153This could easily lead to an explosion of vtables as it has the most fine
    150154grained resolution the number of bindings in a single scope (that produces
    151155the same binding) could be quite high. Merging identical vtables might help
     
    156160
    157161Vtables interact badly with the thunk issue. Conceptually vtables are static
    158 like type/function data they carry, as those decitions are made by the
     162like type/function data they carry, as those decisions are made by the
    159163resolver at compile time.
    160164
    161165Stack allocated functions interact badly with this because they are not
    162 static. There are serveral ways to try to resolve this, however without a
     166static. There are several ways to try to resolve this, however without a
    163167general solution most can only buy time.
    164168
     
    168172
    169173Dynamically allocated vtables introduces memory management overhead and
    170 requires some way to differentate between dynamic and statically allocated
     174requires some way to differentiate between dynamic and statically allocated
    171175tables. The stale function pointer problem continues unless those becomes
    172176dynamically allocated as well which gives us the same costs again.
     
    175179is now the limiting factor but it should be effectively the same as the
    176180shortest lifetime of a function assigned to it. However this still limits the
    177 lifetime "implicately" and returns to the original problem with thunks.
     181lifetime "implicitly" and returns to the original problem with thunks.
Note: See TracChangeset for help on using the changeset viewer.