Updated Roadmap (markdown)
This commit is contained in:
Araq
parent
bef2d4ad7e
commit
63bc7757fa
429
Roadmap.md
429
Roadmap.md
|
|
@ -1,272 +1,157 @@
|
|||
<table>
|
||||
|
||||
<tr>
|
||||
<th>Language feature</th>
|
||||
|
||||
<th>Scheduled for</th>
|
||||
|
||||
<th>Notes</th>
|
||||
|
||||
</tr>
|
||||
|
||||
|
||||
|
||||
<tr>
|
||||
<td>Automatic dereference in more contexts</td>
|
||||
|
||||
<td>0.9.6</td>
|
||||
|
||||
<td>important to be able to write more generic containers easily</td>
|
||||
|
||||
</tr>
|
||||
|
||||
|
||||
|
||||
<tr>
|
||||
<td>support overloading of the assignment operator</td>
|
||||
|
||||
<td>0.9.6</td>
|
||||
|
||||
<td>like <tt class="docutils literal"><span class="pre">fields</span></tt> and destructors an assignment operator needs to be lifted</td>
|
||||
|
||||
</tr>
|
||||
|
||||
|
||||
|
||||
<tr>
|
||||
<td>destructors need to interact with finalizers</td>
|
||||
|
||||
<td>0.9.6</td>
|
||||
|
||||
<td>destructors and finalizers are implemented, but do not interact. <tt class="docutils literal"><span class="pre">new</span></tt> which takes a finalizer needs to be deprecated. People should use a destructor instead</td>
|
||||
|
||||
</tr>
|
||||
|
||||
|
||||
|
||||
<tr>
|
||||
<td>the new concurrency model</td>
|
||||
|
||||
<td>0.9.6</td>
|
||||
|
||||
<td>this requires frontend and backend changes, but no changes to the runtime/GC</td>
|
||||
|
||||
</tr>
|
||||
|
||||
|
||||
|
||||
<tr>
|
||||
<td>weaken the requirements for forward declarations</td>
|
||||
|
||||
<td>after 1.0</td>
|
||||
|
||||
<td>two different design ideas exist: one conservative and so will work, the other highly experimental</td>
|
||||
|
||||
</tr>
|
||||
|
||||
|
||||
|
||||
<tr>
|
||||
<td>comment handling is weird</td>
|
||||
|
||||
<td>0.9.6</td>
|
||||
|
||||
<td>comments should be optional and not part of the grammar, unless it is a documentation comment</td>
|
||||
|
||||
</tr>
|
||||
|
||||
|
||||
|
||||
<tr>
|
||||
<td>push pragma needs to be reworked</td>
|
||||
|
||||
<td>after 1.0</td>
|
||||
|
||||
<td>it should be distinguished between 'push' for 'type', 'proc' etc.</td>
|
||||
|
||||
</tr>
|
||||
|
||||
|
||||
|
||||
<tr>
|
||||
<td>pragmas are not supported for 'bindSym'</td>
|
||||
|
||||
<td>0.9.6</td>
|
||||
|
||||
<td>this makes clean macros impossible to write when it comes to pragmas</td>
|
||||
|
||||
</tr>
|
||||
|
||||
|
||||
|
||||
<tr>
|
||||
<td>type checking for tuples</td>
|
||||
|
||||
<td>0.9.8</td>
|
||||
|
||||
<td>needs to be refined. Recursive tuples should be forbidden.</td>
|
||||
|
||||
</tr>
|
||||
|
||||
|
||||
|
||||
<tr>
|
||||
<td>extended macros API</td>
|
||||
|
||||
<td>0.9.8</td>
|
||||
|
||||
<td>missing: an API for working with types; the builtin getImpl</td>
|
||||
|
||||
</tr>
|
||||
|
||||
|
||||
|
||||
<tr>
|
||||
<td>write tracking</td>
|
||||
|
||||
<td>0.9.8</td>
|
||||
|
||||
<td>algorithm exists. Can be extended to compute lent pointers.</td>
|
||||
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>asFunc pragma</td>
|
||||
<td>0.9.8</td>
|
||||
<td>provides a nice bridge from 'var T' to 'returns T'; can be entirely implemented as a macro with the upcoming types API
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>prevent object branch transitions from low(selector)</td>
|
||||
|
||||
<td>after 1.0</td>
|
||||
|
||||
<td>object branch transitions from low(selector) are allowed, because they are simply too useful, but can break memory safety. Now that the language has a proper notion of construction, we can make them safe.</td>
|
||||
|
||||
</tr>
|
||||
|
||||
|
||||
|
||||
<tr>
|
||||
<td><tt class="docutils literal"><span class="pre">~</span></tt> operator for effects</td>
|
||||
|
||||
<td>after 1.0</td>
|
||||
|
||||
<td>it is not entirely clear what <tt class="docutils literal"><span class="pre">~F</span></tt> should mean.</td>
|
||||
|
||||
</tr>
|
||||
|
||||
|
||||
|
||||
<tr>
|
||||
<td>some effects like <tt class="docutils literal"><span class="pre">GCMem</span></tt> don't need to be white-listed</td>
|
||||
|
||||
<td>after 1.0</td>
|
||||
|
||||
<td>unclear whether this only affects built-in properties like <tt class="docutils literal"><span class="pre">GCMem</span></tt>, <tt class="docutils literal"><span class="pre">Recursive</span></tt>.</td>
|
||||
|
||||
</tr>
|
||||
|
||||
|
||||
|
||||
<tr>
|
||||
<td>returning 'var T' is unsafe and needs static analysis to make safe</td>
|
||||
|
||||
<td>after 1.0</td>
|
||||
|
||||
<td>the compiler already checks for trivial examples</td>
|
||||
|
||||
</tr>
|
||||
|
||||
|
||||
|
||||
<tr>
|
||||
<td>alias analysis needs to specified and controllable with pragmas</td>
|
||||
|
||||
<td>after 1.0</td>
|
||||
|
||||
<td>alias analysis affects memory safety rules</td>
|
||||
|
||||
</tr>
|
||||
|
||||
|
||||
|
||||
<tr>
|
||||
<td>term rewriting macros need more love</td>
|
||||
|
||||
<td>after 1.0</td>
|
||||
|
||||
<td>we need much more tests and use them in production</td>
|
||||
|
||||
</tr>
|
||||
|
||||
|
||||
<tr>
|
||||
<th>Compiler feature</th>
|
||||
|
||||
<th>Scheduled for</th>
|
||||
|
||||
<th>Notes</th>
|
||||
|
||||
</tr>
|
||||
|
||||
|
||||
|
||||
<tr>
|
||||
<td>high level optimizer</td>
|
||||
|
||||
<td>after 1.0</td>
|
||||
|
||||
<td>use the effect system for optimizations; interacts with TR macros;
|
||||
performs:<ul>
|
||||
<li>GCSE</li>
|
||||
|
||||
<li>loop invariant hoisting</li>
|
||||
|
||||
<li>escape analysis for string/seq</li>
|
||||
|
||||
<li>inlining of small lambdas</li>
|
||||
|
||||
</ul>
|
||||
|
||||
</td>
|
||||
|
||||
</tr>
|
||||
|
||||
|
||||
|
||||
<tr><td>pure RC'ing GC</td>
|
||||
|
||||
<td>after 1.0</td>
|
||||
|
||||
<td>important for better interoperability with Objective-C</td>
|
||||
|
||||
</tr>
|
||||
|
||||
|
||||
|
||||
<tr>
|
||||
<td>GPU backend</td>
|
||||
|
||||
<td>after 1.0</td>
|
||||
</tr>
|
||||
|
||||
|
||||
|
||||
<tr>
|
||||
<td>symbol files</td>
|
||||
|
||||
<td>after 1.0</td>
|
||||
<td>symbol files provide true incremental compilation beyond the caching of generated C code</td>
|
||||
</tr>
|
||||
|
||||
|
||||
|
||||
<tr>
|
||||
<td>deterministic code generation</td>
|
||||
|
||||
<td>0.9.8</td>
|
||||
<td>deterministic code generation makes C code caching much more effective</td>
|
||||
</tr>
|
||||
|
||||
</table>
|
||||
<table>
|
||||
<tr>
|
||||
<th>Language feature</th>
|
||||
<th>Scheduled for</th>
|
||||
<th>Notes</th>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>Automatic dereference in more contexts</td>
|
||||
<td>0.9.6</td>
|
||||
<td>important to be able to write more generic containers easily</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>support overloading of the assignment operator</td>
|
||||
<td>0.9.8</td>
|
||||
<td>like <tt class="docutils literal"><span class="pre">fields</span></tt> and destructors an assignment operator needs to be lifted</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>destructors need to interact with finalizers</td>
|
||||
<td>after 1.0</td>
|
||||
<td>destructors and finalizers are implemented, but do not interact. <tt class="docutils literal"><span class="pre">new</span></tt> which takes a finalizer needs to be deprecated. People should use a destructor instead</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>the new concurrency model</td>
|
||||
<td>0.9.6</td>
|
||||
<td>this requires frontend and backend changes, but no changes to the runtime/GC</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>weaken the requirements for forward declarations</td>
|
||||
<td>after 1.0</td>
|
||||
<td>two different design ideas exist: one conservative and so will work, the other highly experimental</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>comment handling is weird</td>
|
||||
<td>0.9.6</td>
|
||||
<td>comments should be optional and not part of the grammar, unless it is a documentation comment</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>push pragma needs to be reworked</td>
|
||||
<td>after 1.0</td>
|
||||
<td>it should be distinguished between 'push' for 'type', 'proc' etc.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>pragmas are not supported for 'bindSym'</td>
|
||||
<td>0.9.6</td>
|
||||
<td>this makes clean macros impossible to write when it comes to pragmas</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>type checking for tuples</td>
|
||||
<td>0.9.8</td>
|
||||
<td>needs to be refined. Recursive tuples should be forbidden.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>extended macros API</td>
|
||||
<td>0.9.8</td>
|
||||
<td>missing: an API for working with types; the builtin getImpl</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>write tracking</td>
|
||||
<td>after 1.0</td>
|
||||
<td>algorithm exists. Can be extended to compute lent pointers.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>asFunc pragma</td>
|
||||
<td>0.9.8</td>
|
||||
<td>provides a nice bridge from 'var T' to 'returns T'; can be entirely implemented as a macro with the upcoming types API
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>prevent object branch transitions from low(selector)</td>
|
||||
<td>after 1.0</td>
|
||||
<td>object branch transitions from low(selector) are allowed, because they are simply too useful, but can break memory safety. Now that the language has a proper notion of construction, we can make them safe.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td><tt class="docutils literal"><span class="pre">~</span></tt> operator for effects</td>
|
||||
<td>after 1.0</td>
|
||||
<td>it is not entirely clear what <tt class="docutils literal"><span class="pre">~F</span></tt> should mean.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>some effects like <tt class="docutils literal"><span class="pre">GCMem</span></tt> don't need to be white-listed</td>
|
||||
<td>after 1.0</td>
|
||||
<td>unclear whether this only affects built-in properties like <tt class="docutils literal"><span class="pre">GCMem</span></tt>, <tt class="docutils literal"><span class="pre">Recursive</span></tt>.</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>returning 'var T' is unsafe and needs static analysis to make safe</td>
|
||||
<td>after 1.0</td>
|
||||
<td>the compiler already checks for trivial examples</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>alias analysis needs to specified and controllable with pragmas</td>
|
||||
<td>after 1.0</td>
|
||||
<td>alias analysis affects memory safety rules</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>term rewriting macros need more love</td>
|
||||
<td>after 1.0</td>
|
||||
<td>we need much more tests and use them in production</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<th>Compiler feature</th>
|
||||
<th>Scheduled for</th>
|
||||
<th>Notes</th>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>high level optimizer</td>
|
||||
<td>after 1.0</td>
|
||||
<td>use the effect system for optimizations; interacts with TR macros;
|
||||
performs:<ul>
|
||||
<li>GCSE</li>
|
||||
<li>loop invariant hoisting</li>
|
||||
<li>escape analysis for string/seq</li>
|
||||
<li>inlining of small lambdas</li>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
<tr><td>pure RC'ing GC</td>
|
||||
<td>after 1.0</td>
|
||||
<td>important for better interoperability with Objective-C</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>GPU backend</td>
|
||||
<td>after 1.0</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>symbol files</td>
|
||||
<td>after 1.0</td>
|
||||
<td>symbol files provide true incremental compilation beyond the caching of generated C code</td>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td>deterministic code generation</td>
|
||||
<td>0.9.8</td>
|
||||
<td>deterministic code generation makes C code caching much more effective</td>
|
||||
</tr>
|
||||
|
||||
</table>
|
||||
|
|
|
|||
Loading…
Reference in New Issue