fixed markdown notation in RAP6

Author: jurgenvinju

courses/RascalAmendmentProposals/RAP6/RAP6.md

@@ -12,16 +12,16 @@ sidebar_position: 6
 
 ### Issue
 
-We have received reports, and encountered ourselves, some baffling emergent behavior of the current semantics of \`import\` and \`extend\` module semantics in Rascal. We see unexpected and complex behaviors, often after long debugging sessions, where the implementation is not wrong per se, but just very hard to get. Ergo, we have to do something about the design of these two language features. It’s not comprehensible now.
+We have received reports, and encountered ourselves, some baffling emergent behavior of the current semantics of `import` and `extend` module semantics in Rascal. We see unexpected and complex behaviors, often after long debugging sessions, where the implementation is not wrong per se, but just very hard to get. Ergo, we have to do something about the design of these two language features. It’s not comprehensible now.
 
 ### Analysis
 
 First the current relevant features of import and extend are listed:
 
-* “import X;” makes the declared items (variables, functions, data-types and syntax-definitions) of the imported module “X” visible in the importing module.  
+* `import X;` makes the declared items (variables, functions, data-types and syntax-definitions) of the imported module “X” visible in the importing module.  
 * An “imported” module is a singleton instance, with its own module state with respect to its global variables  
   * If more than one importer modules A and B import the same imported module X, they share the same view on the state of the imported module X.  
-* “import X;” does not make the declared items of modules it imports itself visible to the importing module. Import is not transitive.   
+* `import X;` does not make the declared items of modules it imports itself visible to the importing module. Import is not transitive.   
   * This is like Java import also works and what our (beginner) audience expects   
   * It helps to keep namespaces clean  
   * It is therefore necessary for information hiding and reuse   
@@ -32,7 +32,7 @@ First the current relevant features of import and extend are listed:
   * This behavior stems from a time when “extend” did not exist yet in Rascal. It’s a backward compatibility issue. When “extend” did not exist yet, this was the only reason why data-types, syntax definitions could be (marginally) modularly extensible. The “extend” feature was added later because this is not enough, in combination with extensible overloaded functions.  
   * When we added extensible overloaded recursive functions over the extensible data-types it became also urgent to add “extend”.
 
-* “extend X”; like “import” also makes the declared items (variables, functions, data-types and syntax-definitions) of the imported module “X” visible in the importing module.  
+* `extend X`; like `import` also makes the declared items (variables, functions, data-types and syntax-definitions) of the imported module “X” visible in the importing module.  
 * An “extended” module is not an instance and it does not have state.  
   * Instead of making reference to an external module instance, all its declarations are cloned into the local scope of the extending module  
   * This also goes for global variables. Each extended global has its own instance in the extending module.  
@@ -46,15 +46,17 @@ First the current relevant features of import and extend are listed:
   * By effectively merging the declarations of data-types and syntax-definitions and functions into the same extending module, both recursive functions and recursive data and syntax types are now openly extensible  
   * Recursive calls in extended modules now resolve to the bigger overloaded function rather than to the overloaded function as it was in the original scope.
 
-**Observation 1:** by not shadowing names declared by imported modules, “import” merges definitions almost like “extend” does, but not completely transitively and recursively. The **semi-merge** surely generates hard-to-predict run-time behavior (why did this function not match?)
+
+> **Observation 1:** by not shadowing names declared by imported modules, “import” merges definitions almost like “extend” does, but not completely transitively and recursively. The **semi-merge** surely generates hard-to-predict run-time behavior (why did this function not match?)
+
 
 * Never static errors are produced that this semi-merging is going on
 
-**Observation 2:** open extensibility is for data-types (languages) and recursive functions that operate on these data-types is a distinguishing Rascal feature with a strong language-oriented flavor. It is an important (yet advanced) language feature. “Extend” does not have any information hiding feature, which is necessary for the “openness” it requires.
+> **Observation 2:** open extensibility is for data-types (languages) and recursive functions that operate on these data-types is a distinguishing Rascal feature with a strong language-oriented flavor. It is an important (yet advanced) language feature. “Extend” does not have any information hiding feature, which is necessary for the “openness” it requires.
 
-**Observation 3:** “import” is useful for libraries of non-extensible functions and specifically for information hiding. We can not do without “import” either: larger Rascal programs would become nearly impossible to write and maintain (remember ASF+SDF which only had “extend” semantics for its “import” declarations).
+> **Observation 3:** “import” is useful for libraries of non-extensible functions and specifically for information hiding. We can not do without “import” either: larger Rascal programs would become nearly impossible to write and maintain (remember ASF+SDF which only had “extend” semantics for its “import” declarations).
 
-**Observation 4:** the feature interactions between import and extend are gruesome. 
+> **Observation 4:** the feature interactions between import and extend are currently "gruesome"; unpredictable, with complex consequences, and no method of debugging. 
 
 * With globals involved, it becomes unclear what instance we are talking about  
 * With function merging involved it becomes unclear which overloaded alternatives are active at which level in the import/extend hierarchy
@@ -86,16 +88,19 @@ Positive consequences:
 
 By affecting this change, the type checker will start producing more warnings and errors automatically. For example:
 
+```rascal
 module A;  
 import basic/Identifiers;
 
 module B;  
 import A;
 
 syntax Exp \= Id; // error undeclared non-terminal Id (before it would get the Id from basic/Identifiers via the transitive import of A).
+```
 
 and:
 
+```rascal
 module A
 
 data X \= x(); 
@@ -108,7 +113,8 @@ import A;
 // X shadows the X from module A:  
 data X \= y(X x); // possible warning: X is not productive, there is no base case
 
-int f(y(x())) \= 1 // undeclared constructor x on local type \`X\`
+int f(y(x())) \= 1 // undeclared constructor x on local type `X`
+```
 
 Negative consequences: