Index: doc/theses/mike_brooks_MMath/list.tex =================================================================== --- doc/theses/mike_brooks_MMath/list.tex (revision e78d9696cdf69e1bc5f317be2b6c9f1e1c21146e) +++ doc/theses/mike_brooks_MMath/list.tex (revision bb9897ca4557693d413d432fa46eb70dbd3adbd0) @@ -30,5 +30,5 @@ In the example, there are implicit conversions from @S@ to @U@ and @S@ to @W@, extracting the appropriate value or pointer for the substructure. \VRef[Figure]{f:DiamondInheritancePattern} shows complex multiple inheritance patterns are possible, like the \newterm{diamond pattern}~\cite[\S~6.1]{Stroustrup89}\cite[\S~4]{Cargill91}. -Currently, \CFA type-system does not support @virtual@ inheritance. +Currently, the \CFA type-system does not support @virtual@ inheritance. \begin{figure} @@ -55,5 +55,6 @@ struct R : @public B@ { int r, w; }; struct T : @public L, R@ { int t; }; - + T + B L B R T t = { { { 5 }, 3, 4 }, { { 8 }, 6, 7 }, 3 }; t.t = 42; @@ -68,5 +69,6 @@ struct R { @inline B;@ int r, w; }; struct T { @inline L; inline R;@ int t; }; - + T + B L B R T t = { { { 5 }, 3, 4 }, { { 8 }, 6, 7 }, 3 }; t.t = 42; @@ -88,5 +90,5 @@ \subsection{Core Design Issues} -The doubly-linked list attaches links intrusively, supports multiple link axes, integrates with user code via the type system, treats its ends uniformly, and identifies a list using an explicit head. +The doubly-linked list attaches links intrusively in a node, allows a node to appear on multiple lists (axes) simultaneously, integrates with user code via the type system, treats its ends uniformly, and identifies a list using an explicit head. This design covers system and data management issues stated in \VRef{toc:lst:issue}. @@ -128,5 +130,5 @@ \end{figure} -\VRef[Figure]{fig:lst-features-multidir} shows how the \CFA library supports multi-inline links, so a node can be on one or more lists simultaneously (axes). +\VRef[Figure]{fig:lst-features-multidir} shows how the \CFA library supports multi-inline links, so a node has multiple axes. The declaration of @req@ has two inline-inheriting @dlink@ occurrences. The first of these gives a type named @req.by_pri@, @req@ inherits from it, and it inherits from @dlink@. @@ -135,24 +137,26 @@ The declarations of the list-head objects, @reqs_pri@, @reqs_rqr_42@, @reqs_rqr_17@, and @reqs_rqr_99@, bind which link nodes in @req@ are used by this list. -Hence, the type of the variable @reqs_pri@, @dlist(req, req.by_pri)@, means operations called on @reqs_pri@ implicitly select (disambiguate) the correct @dlink@s, \eg the calls @insert_first(reqs_pri, ...)@ imply, ``here, we are working by priority.'' +Hence, the type of the variable @reqs_pri@, @dlist(req, req.by_pri)@, means operations on @reqs_pri@ implicitly select (disambiguate) the correct @dlink@s, \eg the calls @insert_first(reqs_pri, ...)@ imply, ``here, we are working by priority.'' As in \VRef[Figure]{fig:lst-issues-multi-static}, three lists are constructed, a priority list containing all nodes, a list with only nodes containing the value 42, and a list with only nodes containing the value 17. \begin{figure} \centering + \begin{tabular}{@{}ll@{}} -\begin{tabular}{@{}l@{}} - \lstinput{20-31}{lst-features-multidir.run.cfa} \\ - \lstinput{43-71}{lst-features-multidir.run.cfa} - \end{tabular} - & - \lstinput[language=C++]{20-60}{lst-issues-multi-static.run.c} +\multicolumn{1}{c}{\CFA} & \multicolumn{1}{c}{C} \\ + \begin{tabular}{@{}l@{}} + \lstinput{20-31}{lst-features-multidir.run.cfa} \\ + \lstinput{43-71}{lst-features-multidir.run.cfa} \end{tabular} +& + \lstinput[language=C++]{20-60}{lst-issues-multi-static.run.c} +\end{tabular} \caption{ - Demonstration of multiple static link axes done in the \CFA list library. - The right example is from \VRef[Figure]{fig:lst-issues-multi-static}. - The left \CFA example does the same job. - } - \label{fig:lst-features-multidir} + Demonstration of multiple static link axes done in the \CFA list library. + The right example is from \VRef[Figure]{fig:lst-issues-multi-static}. + The left \CFA example does the same job. +} +\label{fig:lst-features-multidir} \end{figure} @@ -200,7 +204,4 @@ Finally, the library is separately compiled from the usage code, modulo inlining. -The \CFA library works in headed and headless modes. -\PAB{TODO: elaborate.} - \section{List API} @@ -209,7 +210,7 @@ \begin{itemize}[leftmargin=*] \item -@isListed@ returns true if the node is an element of a list and false otherwise. -\item -@isEmpty@ returns true if the list has no nodes and false otherwise. +@listed@ returns true if the node is an element of a list and false otherwise. +\item +@empty@ returns true if the list has no nodes and false otherwise. \item @first@ returns a reference to the first node of the list without removing it or @0p@ if the list is empty. @@ -231,7 +232,7 @@ @advance@ returns true if the iterator cursor is advanced to the next (successor, towards last) node after the prior cursor node and false otherwise. \item -@isFirst@ returns true if the node is the first node in the list and false otherwise. -\item -@isLast@ returns true if the node is the last node in the list and false otherwise. +@first@ returns true if the node is the first node in the list and false otherwise. +\item +@last@ returns true if the node is the last node in the list and false otherwise. \item @pred@ returns a reference to the previous (predecessor, towards first) node before a specified node or @0p@ if a specified node is the first node in the list. @@ -252,9 +253,12 @@ The node must be in the @from@ list. \end{itemize} +For operations @insert_*@, @insert@, and @remove@, a variable-sized list of nodes can be specified using \CFA's tuple type~\cite[\S~4.7]{Moss18} (not discussed), \eg @insert( list, n1, n2, n3 )@, recursively invokes @insert( list, n@$_i$@ )@.\footnote{ +Currently, a resolver bug between tuple types and references means tuple routines must use pointer parameters. +Nevertheless, the imaginary reference versions are used here as the code is cleaner, \eg no \lstinline{&} on call arguments.} \begin{figure} \begin{cfa} -E & isListed( E & node ); -E & isEmpty( dlist( E ) & list ); +E & listed( E & node ); +E & empty( dlist( E ) & list ); E & first( dlist( E ) & list ); E & last( dlist( E ) & list ); @@ -265,10 +269,10 @@ bool advance( E && refx ); bool recede( E && refx ); -bool isFirst( E & node ); -bool isLast( E & node ); +bool first( E & node ); +bool last( E & node ); E & prev( E & node ); E & next( E & node ); E & insert_first( dlist( E ) & list, E & node ); -E & insert_last( dlist( E ) & list, E & node ); +E & insert_last( dlist( E ) & list, E & node ); // synonym insert E & remove_first( dlist( E ) & list ); E & remove_last( dlist( E ) & list ); @@ -284,5 +288,5 @@ It is possible to iterate through a list manually or using a set of standard macros. -\VRef[Figure]{f:IteratorTemple} shows the iterator template, managing a list of nodes, used throughout the following iterator examples. +\VRef[Figure]{f:IteratorDriver} shows the iterator outline, managing a list of nodes, used throughout the following iterator examples. Each example assumes its loop body prints the value in the current node. @@ -291,5 +295,4 @@ #include #include - struct node { int v; @@ -299,12 +302,12 @@ dlist(node) list; node n1 = { 1 }, n2 = { 2 }, n3 = { 3 }, n4 = { 4 }; - insert( list, n1 ); insert( list, n2 ); insert( list, n3 ); insert( list, n4 ); + insert( list, n1, n2, n3, n4 ); $\C{// insert in any order}$ sout | nlOff; - for ( ... ) @sout | it.v | ","; sout | nl;@ // iterator examples in text - remove( n1 ); remove( n2 ); remove( n3 ); remove( n4 ); + @for ( ... )@ sout | it.v | ","; sout | nl; $\C{// iterator examples in text}$ + remove( n1, n2, n3, n4 ); $\C{// remove in any order}$ } \end{cfa} -\caption{Iterator Temple} -\label{f:IteratorTemple} +\caption{Iterator Driver} +\label{f:IteratorDriver} \end{figure} @@ -361,5 +364,5 @@ \end{tabular} \end{cquote} -Iterating forward and reverse through the entire list using the shorthand start at the list head and pick a axis. +Iterating forward and reverse through the entire list using the shorthand start at the list head and pick an axis. In this case, @advance@ and @recede@ return a boolean, like \CC @while ( cin >> i )@. \begin{cquote} @@ -496,5 +499,5 @@ With this change, both @begin ~ end@ and @end@ (in context of the latter ``two-place for'' expression) parse as \emph{ranges}, and the loop syntax becomes, simply: \begin{cfa} - for( elem; rangeExpr ) + for( elem; rangeExpr ) \end{cfa} The expansion and underlying API are under discussion. @@ -517,10 +520,103 @@ +\section[C++ Lists]{\CC Lists} + +It is worth addressing two API issues in \CC lists avoided in \CFA. +First, \CC lists require two steps to remove a node versus one in \CFA. +\begin{cquote} +\begin{tabular}{@{}ll@{}} +\multicolumn{1}{c}{\CC} & \multicolumn{1}{c}{\CFA} \\ +\begin{c++} +list li; +node n = li.first(); // assignment could raise exception +li.pop_front(); +\end{c++} +& +\begin{cfa} +dlist(node) list; +node n = remove_first( list ); + +\end{cfa} +\end{tabular} +\end{cquote} +The argument for two steps is exception safety: returning an unknown T by value/move might throw an exception from T's copy/move constructor. +Hence, to be \emph{exception safe}, all internal list operations must complete before the copy/move so the list is consistent should the return fail. +This coding style can result in contrived code, but is usually possible; +however, it requires the container designer to anticipate the potential throw. +(Note, this anticipation issue is pervasive in exception systems, not just with containers.) +The solution moves the coding complexity from the container designer to the programer~\cite[ch~10, part 3]{Sutter99}. +First, obtain the node, which might fail, but the container is unmodified. +Second, remove the node, which modifies the container without the possibly of an exception. +This movement of responsibility increases the cognitive effort for programmers. +Unfortunately, this \emph{single-responsibility principle}, \ie preferring separate operations, is often repeated as a necessary requirement rather an an optional one. +Separate operations should always be available, but their composition should also be available. +Interestingly, this issue does not apply to intrusive lists, because the node data is never copied/moved in or out of a list; +only the link fields are accessed in list operations. + +Second, \VRef[Figure]{f:CCvsCFAListIssues} shows an example where a \CC list operation is $O(N$) rather than $O(1)$ in \CFA. +This issue is inherent to wrapped (non-intrusive) lists. +Specifically, to remove a node requires access to the links that materialize its membership. +In a wrapped list, there is no access from node to links, and for abstract reasons, no direct pointers to wrapped nodes, so the links must be found indirectly by navigating the list. +The \CC iterator is the abstraction to navigate wrapped links. +So an iterator is needed, not because it offers go-next, but for managing the list membership. +Note, attempting to keep an array of iterators to each node requires high-complexity to ensure the list and array are harmonized. + +\begin{figure} +\begin{tabular}{@{}ll@{}} +\multicolumn{1}{c}{\CC} & \multicolumn{1}{c}{\CFA} \\ +\begin{c++} +list list; +node n1 = { 1 }, n2 = { 2 }, n3 = { 3 }, n4 = { 4 }; +list.push_back( &n1 ); list.push_back( &n2 ); +list.push_back( &n3 ); list.push_back( &n4 ); +list::iterator it; +for ( it = list.begin(); it != list.end(); it ++ ) + if ( *it == &n3 ) { dl.erase( it ); break; } +\end{c++} +& +\begin{cfa} +dlist(node) list; +node n1 = { 1 }, n2 = { 2 }, n3 = { 3 }, n4 = { 4 }; +insert( list, n1, n2, n3, n4 ); + + + +remove( list, n3 ); +\end{cfa} +\end{tabular} +\caption{\CC \vs \CFA List Issues} +\label{f:CCvsCFAListIssues} +\end{figure} + +\begin{comment} +Dave Dice: +There are what I'd call the "dark days" of C++, where the language \& libraries seemed to be getting progressively uglier - requiring more tokens to express something simple, and lots of arcana. +But over time, somehow, they seem to have mostly righted the ship and now I can write C++ code that's fairly terse, like python, by ignoring all the old constructs. +(They carry around the legacy baggage, of course, but seemed to have found a way to evolve away from it). + +If you just want to traverse a std::list, then, using modern "for" loops, you never need to see an iterator. +I try hard never to need to write X.begin() or X.end(). +(There are situations where I'll expose iterators for my own types, however, to enable modern "for" loops). +If I'm implementing simple linked lists, I'll usually skip std:: collections and do it myself, as it's less grief. +I just don't get that much advantage from std::list. And my code is certainly not any shorter. +On the other hand, @std::map@, @unordered_map@, @set@, and friends, are terrific, and I can usually still avoid seeing any iterators, which are blight to the eye. +So those are a win and I get to move up an abstraction level, and write terse but easily understood code that still performs well. +(One slight concern here is that all the C++ collection/container code is templated and lives in include files, and not traditional libraries. +So the only way to replace something - say with a better algorithm, or you have a bug in the collections code - is to boil the oceans and recompile everything. +But on the other hand the compiler can specialize to the specific use case, which is often a nice performance win). + +And yeah, the method names are pretty terrible. I think they boxed themselves in early with a set of conventions that didn't age well, and they tried to stick with it and force regularity over the collection types. + +I've never seen anything written up about the history, although lots of the cppcon talks make note of the "bad old days" idea and how collection \& container library design evolved. The issue is certainly recognized. +\end{comment} + + \section{Implementation} -\VRef[Figure]{fig:lst-impl-links} continues the running @req@ example, now showing the \CFA list library's internal representation. +\VRef[Figure]{fig:lst-impl-links} continues the running @req@ example, showing the \CFA list library's internal representation. The @dlink@ structure contains exactly two pointers: @next@ and @prev@, which are opaque. -Even though the user-facing list model is linear, the CFA library implements all listing as circular. -This choice helps achieve uniform end treatment and \PAB{TODO finish summarizing benefit}. +Even though the user-facing list model is linear, the \CFA library implements all listing as circular. +This choice helps achieve uniform end treatment. +% and \PAB{TODO finish summarizing benefit}. A link pointer targets a neighbouring @dlink@ structure, rather than a neighbouring @req@. (Recall, the running example has the user putting a @dlink@ within a @req@.) @@ -530,5 +626,5 @@ \includegraphics[width=\textwidth]{lst-impl-links.pdf} \caption{ - \CFA list library representations for the cases under discussion. + \CFA list library representations for headed and headless lists. } \label{fig:lst-impl-links} @@ -540,4 +636,5 @@ Hence, the tags are set on the links that a user cannot navigate. +The \CFA library works in headed and headless modes. In a headed list, the list head (@dlist(req)@) acts as an extra element in the implementation-level circularly-linked list. The content of a @dlist@ header is a (private) @dlink@, with the @next@ pointer to the first element, and the @prev@ pointer to the last element. @@ -567,12 +664,12 @@ This experiment takes the position that: -\begin{itemize} - \item The total time to add and remove is relevant \vs individual times for add and remove. - Adds without removes quickly fill memory; +\begin{itemize}[leftmargin=*] + \item The total time to add and remove is relevant \vs individual times for add and remove. + Adds without removes quickly fill memory; removes without adds is meaningless. - \item A relevant breakdown ``by operation'' is: + \item A relevant breakdown ``by operation'' is: \begin{description} \item[movement] - Is the add/remove applied to a stack, queue, or something else? + Is the add/remove applied to a stack, queue, or something else? \item[polarity] In which direction does the action apply? @@ -580,8 +677,8 @@ For a stack, is the first or last end used for adding and removing? \item[accessor] - Is an add/remove location given by a list head's ``first''/``last'', or by a reference to an individual element? + Is an add/remove location given by a list head's first/last, or by a reference to an individual element? \end{description} - \item Speed differences caused by the host machine's memory hierarchy need to be identified and explained, - but do not represent advantages of one linked-list implementation over another. + \item Speed differences caused by the host machine's memory hierarchy need to be identified and explained, + but do not represent advantages of one linked-list implementation over another. \end{itemize} @@ -592,6 +689,6 @@ The experiment is sensitive enough to show: \begin{itemize} - \item intrusive lists performing (majorly) differently than wrapped lists, - \item a space of (minor) performance differences among the intrusive lists. + \item intrusive lists performing (majorly) differently than wrapped lists, + \item a space of (minor) performance differences among the intrusive lists. \end{itemize} @@ -637,5 +734,5 @@ To test list operations, the experiment performs the inserts/removes in different patterns, \eg insert and remove from front, insert from front and remove from back, random insert and remove, \etc. Unfortunately, the @std::list@ does \emph{not} support direct insert/remove from a node without an iterator, \ie no @erase( node )@, even though the list is doubly-linked. -To eliminate the iterator, a trick is used for random insertions without replacement. +To eliminate the iterator, a trick is used for random insertions without replacement, which takes advantage of the array nature of the nodes. The @i@ fields in each node are initialized from @0..n-1@. These @i@ values are then shuffled in the nodes, and the @i@ value is used to represent an indirection to that node for insertion. @@ -761,20 +858,20 @@ & \subfloat[Linear List Nodes, AMD]{\label{f:Linear-swift} - \hspace*{-0.75in} - \includegraphics{plot-list-zoomout-noshuf-swift.pdf} + \hspace*{-0.75in} + \includegraphics{plot-list-zoomout-noshuf-swift.pdf} } % subfigure & \subfloat[Linear List Nodes, Intel]{\label{f:Linear-java} - \includegraphics{plot-list-zoomout-noshuf-java.pdf} + \includegraphics{plot-list-zoomout-noshuf-java.pdf} } % subfigure \\ & \subfloat[Shuffled List Nodes, AMD]{\label{f:Shuffled-swift} - \hspace*{-0.75in} - \includegraphics{plot-list-zoomout-shuf-swift.pdf} + \hspace*{-0.75in} + \includegraphics{plot-list-zoomout-shuf-swift.pdf} } % subfigure & \subfloat[Shuffled List Nodes, Intel]{\label{f:Shuffled-java} - \includegraphics{plot-list-zoomout-shuf-java.pdf} + \includegraphics{plot-list-zoomout-shuf-java.pdf} } % subfigure \end{tabular} @@ -868,20 +965,20 @@ & \subfloat[Absolute Time, AMD]{\label{f:AbsoluteTime-swift} - \hspace*{-0.75in} - \includegraphics{plot-list-zoomin-abs-swift.pdf} + \hspace*{-0.75in} + \includegraphics{plot-list-zoomin-abs-swift.pdf} } % subfigure & \subfloat[Absolute Time, Intel]{\label{f:AbsoluteTime-java} - \includegraphics{plot-list-zoomin-abs-java.pdf} + \includegraphics{plot-list-zoomin-abs-java.pdf} } % subfigure \\ & \subfloat[Relative Time, AMD]{\label{f:RelativeTime-swift} - \hspace*{-0.75in} - \includegraphics{plot-list-zoomin-rel-swift.pdf} + \hspace*{-0.75in} + \includegraphics{plot-list-zoomin-rel-swift.pdf} } % subfigure & \subfloat[Relative Time, Intel]{\label{f:RelativeTime-java} - \includegraphics{plot-list-zoomin-rel-java.pdf} + \includegraphics{plot-list-zoomin-rel-java.pdf} } % subfigure \end{tabular} @@ -914,20 +1011,20 @@ & \subfloat[Supersets, AMD]{\label{f:Superset-swift} - \hspace*{-0.75in} - \includegraphics{plot-list-cmp-exout-swift.pdf} + \hspace*{-0.75in} + \includegraphics{plot-list-cmp-exout-swift.pdf} } % subfigure & \subfloat[Supersets, Intel]{\label{f:Superset-java} - \includegraphics{plot-list-cmp-exout-java.pdf} + \includegraphics{plot-list-cmp-exout-java.pdf} } % subfigure \\ & \subfloat[1st Level Slice, AMD]{\label{f:1stLevelSlice-swift} - \hspace*{-0.75in} - \includegraphics{plot-list-cmp-survey-swift.pdf} + \hspace*{-0.75in} + \includegraphics{plot-list-cmp-survey-swift.pdf} } % subfigure & \subfloat[1st Level Slice, Intel]{\label{f:1stLevelSlice-java} - \includegraphics{plot-list-cmp-survey-java.pdf} + \includegraphics{plot-list-cmp-survey-java.pdf} } % subfigure \end{tabular} @@ -981,5 +1078,5 @@ \begin{comment} -\subsection{Result: CFA cost attribution} +\subsection{Result: \CFA cost attribution} This comparison loosely itemizes the reasons that the \CFA implementation runs 15--20\% slower than LQ. @@ -1078,5 +1175,85 @@ \label{toc:lst:futwork} -The \CFA list examples elide the \lstinline{P9_EMBEDDED} annotations that (TODO: xref P9E future work) proposes to obviate. +Not discussed in the chapter is an issue in the \CFA type system with Plan-9 @inline@ declarations. +It implements the trait 'embedded' for the derived-base pair named in the arguments. +This trait defines a pseudo conversion called backtick-inner, from derived to base (the safe direction). +Such a real conversion exists for the concrete types, due to our compiler having the p9 language feature. +But when trying to be polymorphic over the types, there is no way to access this built-in conversion, so my macro stands in until Fangren does more with conversions. + +An API author has decided that the intended user experience is: +\begin{itemize} +\item +offer the user an opaque type that abstracts the API's internal state +\item +tell the user to extend this type +\item +provide functions with a ``user's type in, user's type out'' style +\end{itemize} +Fig XXX shows several attempts to provide this experience. +The types in (a) give the setup, achieving the first two points, while the pair of function declarations and calls of (b) are unsuccessful attempts at achieving the third point. +Both functions @f1@ and @f2@ allow calls of the form @f( d )@, but @f1@ has the wrong return type (@Base@) for initializing a @Derived@. +The @f1@ signature fails to meet ``user's type out;'' this signature does not give the \emph{user} a usable type. +On the other hand, the signature @f2@ offers the desired user experience, so the API author proceeds with trying to implement it. + +\begin{figure} +\begin{cfa} +#ifdef SHOW_ERRS +#define E(...) __VA_ARGS__ +#else +#define E(...) +#endif + +// (a) +struct Base { /*...*/ }; // system offers +struct Derived { /*...*/ inline Base; }; // user writes + +// (b) +// system offers +Base & f1( Base & ); +forall( T ) T & f2( T & ); +// user writes +void to_elide1() { + Derived & d /* = ... */; + f1( d ); + E( Derived & d1 = f1( d ); ) // error: return is not Derived + Derived & d2 = f2( d ); + + // (d), user could write + Base & b = d; +} + +// (c), system has +static void helper( Base & ); +forall( T ) T & f2( T & param ) { + E( helper( param ); ) // error: param is not Base + return param; +} +static void helper( Base & ) {} + +#include +// (e) +// system offers, has +forall( T | embedded(T, Base, Base) ) + T & f3( T & param ) { + helper( param`inner ); // ok + return param; +} +// user writes +struct DerivedRedux { /*...*/ inline Base; }; +P9_EMBEDDED( DerivedRedux, Base ) +void to_elide2() { + DerivedRedux & dr /* = ... */; + DerivedRedux & dr3 = f3( dr ); + + // (f) + // user writes + Derived & xxx /* = ... */; + E( Derived & yyy = f3( xxx ); ) // error: xxx is not embedded +} +\end{cfa} +\end{figure} + + +The \CFA list examples elide the @P9_EMBEDDED@ annotations that (TODO: xref P9E future work) proposes to obviate. Thus, these examples illustrate a to-be state, free of what is to be historic clutter. The elided portions are immaterial to the discussion and the examples work with the annotations provided. @@ -1110,4 +1287,37 @@ P9_EMBEDDED(fred.yours, dlink(fred)) \end{cfa} + + +The function definition in (c) gives this system-implementation attempt. +The system needs to operate on its own data, stored in the @Base@ part of the user's @d@, now called @param@. +Calling @helper@ represents this attempt to look inside. +It fails, because the @f2@ signature does not state that @param@ has any relationship to @Base@; +this signature does not give the \emph{system} a usable type. +The fact that the user's argument can be converted to @Base@ is lost when going through this signature. + +Moving forward needs an @f@ signature that conveys the relationship that the argument @d@ has to @Base@. +\CFA conveys type abilities, from caller to callee, by way of traits; so the challenge is to state the right trait member. +As initialization (d) illustrates, the @d@--@Base@ capability is an implicit conversion. +Unfortunately, in present state, \CFA does not have a first-class representation of an implicit conversion, the way operator @?{}@ (which is a value), done with the right overload, is arguably an explicit conversion. +So \CFA cannot directly convey ``@T@ compatible with @Base@'' in a trait. + +This work contributes a stand-in for such an ability, tunneled through the present-state trait system, shown in (e). +On the declaration/system side, the trait @embedded@, and its member, @`inner@, convey the ability to recover the @Base@, and thereby call @helper@. +On the user side, the @P9_EMBEDDED@ macro accompanies type definitions that work with @f3@-style declarations. +An option is presemt-state-available to compiler-emit @P9_EMBEDDED@ annotations automatically, upon each occurrence of an `inline` member. +The choice not to is based on conversions in \CFA being a moving target because of separate, ongoing work. + +An intended finished state for this area is achieved if \CFA's future efforts with conversions include: +\begin{itemize} +\item +treat conversion as operator(s), \ie values +\item +re-frame the compiler's current Plan-9 ``magic'' as seeking an implicit conversion operator, rather than seeking an @inline@ member +\item +make Plan-9 syntax cause an implementation of implicit conversion to exist (much as @struct@ syntax causes @forall(T)@ compliance to exist) +\end{itemize} +To this end, the contributed @P9_EMBEDDED@ expansion shows how to implement this conversion. + + like in tests/list/dlist-insert-remove. Future work should autogen those @P9_EMBEDDED@ declarations whenever it sees a plan-9 declaration.