Changeset 3873b5a1 for doc

Timestamp:

Jul 6, 2017, 4:19:50 PM (7 years ago)

Author:

Thierry Delisle <tdelisle@…>

Branches:

ADT, aaron-thesis, arm-eh, ast-experimental, cleanup-dtors, deferred_resn, demangler, enum, forall-pointer-decay, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-ast-unique-expr, new-env, no_list, persistent-indexer, pthread-emulation, qualifiedEnum, resolv-new, with_gc

Children:

eaace25

Parents:

f3c1737 (diff), 9ff56e7 (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' of plg.uwaterloo.ca:software/cfa/cfa-cc

File:

• doc/proposals/tagged-struct.txt (modified) (2 diffs)

doc/proposals/tagged-struct.txt

@@ -71 +71 @@
 should be possible to do during linking.
 
+If a generic/polymorphic type is tagged its tagged would then be shared
+between all applications of that generic. Internal tags could be used to
+seperate these structures again, however it seems in most cases simply using
+the existing type parameters should provide the needed information.
+
 
 Traits:
@@ -102 +107 @@
 To allow for growth each option would have to be a structure itself.
 
-Which brings us to "tagget struct union", ie. a union of tagged structures
+Which brings us to "tagged struct union", ie. a union of tagged structures
 as opposed to tagging the union itself. This extention acts as a constraint.
 If unions are declared tagged instead of creating a new tagged type, all
-possible values of the union must be of that tagged type or a child type.
+possible values of the union must be of that tagged type or a child type. If
+the tagged type is omitted then they must all be tagged but of any tagged
+type.
+
+As a short cut union_instance->type might get the type object of the loaded
+value. It should always be the same operation regardless so it saves
+abritarly picking a branch of the union to get the type object.
 
 
-Custom Type Objects (Extention):
+Type Objects Fields (Extention):
 
-Some method to define type objects used within a tree of types. One option is
-to allow the tree's type object to be specified by the tree root. It would
-then have to be filled in for each type in the tree, including the root.
+Adding fields to the type object allows data to be shared between instances
+of the same type. Such behaviour could be mimiced by creating a lookup
+function on the type object pointer, but this may be cleaner and more
+efficient.
 
-The only required field is the parent field, a pointer to the type object's
-type. (This is also the only required field on the tagged structure itself.)
+The type object fields follow similar rules to the fields on the tagged
+objects themselves, they must be additive. So any fields present on a
+type object will be present (and in the same place) on all of its children.
 
-A further extention could allow expanding type objects, so child types could
-append fields to their parent's feild list. They might need their own type
-objects at that point, or maybe static checks will be enough to see the
-minimum field list.
+This does mean that many type object structure types will have to be auto
+generated, and traversing up the tree might get a little wierd. That could
+be symplified by only allowing the root type to specify fields on the type
+object, so that the type object is consistant throughout that particular tree.
+And hence the type_object pointers would also be consistant as the type they
+point to would never change.
+
+struct Example tagged {
+        tagged char const * const type_name = "Example";
+        int data;
+};
+
+Creates a tagged structure that has no parent, stores an integer and the type
+object also has an extra field that stores a string on the type object.
+This can be accessed by using member access on the type object, as a regular
+structure.
+
+Type object fields will have to allow initialization on their declaration,
+and declarations of children as well, as they are not assotiated with the
+later instances of the tagged structure.
+
+        ...
+        tagged void (*dtor)(tagged Example * this);
+        ...
+
+Sub-Extention, not sure how it would work but some way to have a "dynamic"
+field that is considered the type of the current tagged struct might be useful
+for things like specifying a deconstructor. In this case, the following code
+will clean up any child type of Example:
+
+Example * ex = get_some_example();
+ex->type->dtor(ex);