fixed cross-RAP references and added keywords

Author: jurgenvinju

courses/RascalAmendmentProposals/RAP10/RAP10.md

@@ -12,7 +12,7 @@ sidebar_position: 10
 
 ## Abstract
 
-Rascal can be executed in JVM threads (as in the Eclipse context for example) and also we plan to add concurrency features to Rascal itself (RAP 8). This puts a lot more pressure on our IO mechanism than before, leading to races on disk and on other external resources identified by values of type `loc`.
+Rascal can be executed in JVM threads (as in the Eclipse context for example) and also we plan to add concurrency features to Rascal itself ((RAP8)). This puts a lot more pressure on our IO mechanism than before, leading to races on disk and on other external resources identified by values of type `loc`.
 
 We propose to extend the URIResolverRegistry (which is Rascal’s generic resource access mechanism) with a cross-cutting “locking” feature that is safe (up to *unpredicted* aliasing of location URIs). 
 
@@ -117,7 +117,7 @@ A second part of the proposal is to expose this locking feature on the language
        * `loc (str x, bool append=false)` will write a `str` to the file (replacing it, or appending to it)  
          * Example: `|home:///.bashrc|(“\#\! /bin/bash”);`  
        * Motivation: if `**sync**` is builtin, and does not require importing an IO library, it would be inconsistent to have to import a module to read/write from/to source locations.   
-       * See also **\[RAP 2\]** which avoids importing util::ValueUI and ParseTree by making types simulate parsing functions using the CallOrTree syntax.  
+       * See also ((RAP2)) which avoids importing `util::ValueUI` and `ParseTree` by making types simulate parsing functions using the CallOrTree syntax.  
        * The CallOrTree semantics would be overloaded with one more feature, letting a location “act” as a read/write function.  
          * However, locations are **not** suddenly or accidentally also sub-typed of functions\!   
          * This is \_only\_ about overloading CallOrTree, unambiguously  

courses/RascalAmendmentProposals/RAP14/RAP14.md

@@ -84,8 +84,8 @@ Given the syntax and semantics of Rascal, here we list concrete changes to libra
   * hence extend-x-incompatibility is transitive over the inverse extend relation.  
 * L is extend-x-incompatible (at least) if L is import-x-incompatible.  
 * L is import-x-incompatible if:  
-  * At least one alternative of an overloaded function is removed.[^1] Removing alternatives breaks the dispatch function inside the client module C for the overloaded functions. After RAP 6 this would only happen in modules that *extend* the broken module.  
-  * At least one alternative of an overloaded function is added..[^2] Adding alternatives breaks the dispatch function inside the client module C for the overloaded functions. After RAP 6 this would only happen in modules that *extend* the broken module.  
+  * At least one alternative of an overloaded function is removed.[^1] Removing alternatives breaks the dispatch function inside the client module C for the overloaded functions. After ((RAP6)) this would only happen in modules that *extend* the broken module.  
+  * At least one alternative of an overloaded function is added..[^2] Adding alternatives breaks the dispatch function inside the client module C for the overloaded functions. After ((RAP6)) this would only happen in modules that *extend* the broken module.  
   * An alternative constructor of an ADT is removed (adding is fine)  
   * An alias definition is removed (adding is fine)  
   * A public global variable is removed (adding is fine)  
@@ -103,13 +103,13 @@ Given the syntax and semantics of Rascal, here we list concrete changes to libra
   * An alternative (or more) is added to an overloaded function via  
     * A normal addition typed into the current module  
     * Extending a new module that has the same (overloaded) function as in the current module, or another extended module  
-    * Importing a new module (as above).. *Note that this behavior would change if we apply the simplifications or RAP 6*  
+    * Importing a new module (as above). Note that this behavior would change if we apply the simplifications of (((RAP6)).
   * An alternative (or more) are removed from an overloaded function via:
 
 
 
     * Having been removed from an extended module, or not extending said module anymore.  
-    * Having been removed from an imported module, or not importing said module anymore (see also RAP 6\)  
+    * Having been removed from an imported module, or not importing said module anymore (see also ((RAP 6)) ) 
 * Conversely, this is a list of changes that should be import-compatible and extend-compatible:  
   * Adding non-functional tags to functions (like @synopsis)   
   * Changes to private functions are always import-compatible, but not extend-compatible  

courses/RascalAmendmentProposals/RAP6/RAP6.md

@@ -3,7 +3,7 @@ title: RAP 6 - improved import/extend semantics
 sidebar_position: 6
 ---
 
-| RAP[^1] | 6 |
+| RAP | 6 |
 | :---- | :---- |
 | Title | improved import/extend semantics  |
 | Author | Jurgen Vinju |
@@ -127,4 +127,3 @@ Negative consequences:
     * And such as overloaded functions which miss cases  
   * Suggest qualified names when a function is shadowed but reachable from an import.
 
-[^1]:  RAP is at the moment following Pyhton’s PEP ([https://www.python.org/dev/peps/](https://www.python.org/dev/peps/)). We need to look at other projects to see what is best. See for instance,  [http://yt-project.org/](http://yt-project.org/) 

courses/RascalAmendmentProposals/RAP8/RAP8.md

@@ -18,7 +18,7 @@ The proposal is to introduce a single structured “for-loop-like” programming
 
 The `fork` statement ends when all of its concurrent loop blocks have ended (if it returns results) and it then returns a list of values in the order of spawning each block. If no results are computed, the fork statement ends after spawning all of its computations directly.
 
-As file locations, the `loc` type, in Rascal is highly prominent and these “point” to external file locations and other resources outside of the JVM, the concurrency feature also requires us to think about resource locking. This can be implemented and designed orthogonally, see RAP 10\. 
+As file locations, the `loc` type, in Rascal is highly prominent and these “point” to external file locations and other resources outside of the JVM, the concurrency feature also requires us to think about resource locking. This can be implemented and designed orthogonally, see ((RAP10)). 
 
 ## Motivation