Changeset 2725882 for doc

Timestamp:

Sep 25, 2018, 4:44:52 PM (6 years ago)

Author:

Thierry Delisle <tdelisle@…>

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:

2b3d6ff

Parents:

c6bbcdb (diff), 560812b (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the (diff) links above to see all the changes relative to each parent.

Message:

Merge branch 'master' into shared_library

File:

• doc/proposals/virtual.txt (modified) (4 diffs)

doc/proposals/virtual.txt

@@ -87 +87 @@
 first polymorphic parameter).
 
-Once a function in a trait has been marked as virtual it defines a new
-function that takes in that trait's reference and then dynamically calls the
-underlying type implementation. Hence a trait reference becomes a kind of
-abstract type, cannot be directly instantiated but can still be used.
+Instances of a trait are created by wrapping an existing instance of a type
+that implements that trait. This wrapper includes all the function pointers
+and other values required to preform the dynamic look-up. These are chosen by
+the normal look-up rules at the point of abstraction.
 
 One of the limitations of this design is that it does not support double
@@ -98 +98 @@
 is also restricted, initially forbidden, see extension.
 
+Ownership of the underlying structure is also a bit of a trick. Considering
+the use cases for trait object, it is probably best to have the underlying
+object be heap allocated and owned by the trait object.
+
 Extension: Multi-parameter Virtual Traits:
 
@@ -157 +161 @@
 context, for instance if the cast occurs on the right hand side of an
 assignment.
+
+Function look-up follows the same rules as relaxed (behavioural) inheritance.
+Traits can be upcast and down cast without losing information unless the
+trait is cast down to a structure. Here there are two options.
+
+  Abstraction Time Binding: The more efficient and consistant with other parts
+of CFA. Only the trait types use dynamic look-up, if converveted back into a
+structure the normal static look-up rules find the function at compile time.
+Casting down to a structure type can then result in the loss of a set of
+bindings.
+  Construction Time Binding: For more consistant handling of the virtual
+structs, they are always considered wrapped. Functions are bound to the
+instance the moment it is constructed and remain unchanged throughout its
+lifetime, so down casting does not lose information.
+
+(We will have to decide between one of these two.)
 
 Extension: Multiple Parents
@@ -205 +225 @@
 
 We have so far been silent on how the vtable is created, stored and accessed.
-
-Creation happens at compile time. Function pointers are found by using the
-same best match rules as elsewhere (additional rules for defaults from the
-parent may or may not be required). For strict virtual this must happen at the
-global scope and forbidding static functions, to ensure that a single unique
-vtable is created. Similarly, there may have to be stricter matching rules
-for the functions that go into the vtable, possibly requiring an exact match.
-Relaxed virtual could relax both restrictions, if we allow different vtable
-at different conversion (struct to trait reference) sites. If it is allowed
-local functions being bound to a vtable could cause issues when they go out
-of scope, however this should follow the lifetime rules most C programs
-already follow implicitly.
-
-Most vtables should be stored statically, the only exception being some of
-the relaxed vtables that could have local function pointers. These may be able
-to be stack allocated. All vtables should be immutable and require no manual
-cleanup.
+The vtables for the two types might be handled slightly differently and then
+there is also the hierarchy data for virtual casts.
+
+The hierarchy data is simple conceptually. A single (exactly one copy) pointer
+for each type can act as the identity for it. The value of the pointer is
+its parent type, with the root pointer being NULL. Additional meta-data
+can accompany the parent pointer, such as a string name or the vtable fields.
+
+They types of each vtable can be constructed from the definitions of the
+traits (or internal nodes). The stand alone/base vtable is the same for both
+kinds of inheritance. It may be argumented differently however (include parent
+/this pointer in hierachal inheritance).
+
+Creation of the actual vtable is tricky. For classical single implementation
+semantics we would assemble the functions and create one vtable at compile
+time. However, not only does this not give CFA-like behaviour, it is
+impossible generally because types can satify assertions in different ways at
+different times and stop satifying them. A special set of harder rules could
+be used, instead we have decided to try creating multiple vtables for each
+type. The different vtables will all implement the same type but not always
+in the same way.
+
+Storage has some issues from creation. If the contents of every vtable could
+be determained at compile time they could all be created and stored
+statically. However since thunks can be constructed on the stack and become
+the best match, that isn't always possible. Those will have to be stored in
+dynamic memory. Which means that all vtables must be stored dynamically or
+there must be a way to determain which ones to free when the trait object is
+destroyed.
 
 Access has two main options: