fixed markdown notation in RAP2

Author: jurgenvinju

courses/RascalAmendmentProposals/RAP2/RAP2.md

@@ -12,24 +12,24 @@ sidebar_position: 2
 
 ## Abstract
 
-The goal is to remove a number of features for calling parsers of different types and unify them in a single concept. **This concept is that any Rascal type represents a parser and we should be able to \`call\` this parser using a unified syntax.** We propose to not introduce new syntax at all, but to reuse the function call syntax. To parse using a Rascal type, the function name is represented by a reified type, like so: 
+The goal is to remove a number of features for calling parsers of different types and unify them in a single concept. **This concept is that any Rascal type represents a parser and we should be able to `call` this parser using a unified syntax.** We propose to not introduce new syntax at all, but to reuse the function call syntax. To parse using a Rascal type, the function name is represented by a reified type, like so: 
 
-* \#int(“123”)  
-  * parses the string “123” to the integer \`123\`.   
+* `#int(“123”)`  
+  * parses the string “123” to the integer `123`.   
   * based on rascal expression parser or rascal-value parser  
-* \#start\[CompilationUnit\](|home://myCprogram.c|)  
+* `#start[CompilationUnit](|home://myCprogram.c|)  `
   * uses the parser generated for C compilation units to parse a given C program in the given file.  
   * Based on (data-dependent) Rascal-generated parser
 
-Library functions like \`parse\` and \`readTextValueString\` will become deprecated after this feature has been added. Also the “as type” expression notation is redundant after this addition. 
+Library functions like `parse` and `readTextValueString` will become deprecated after this feature has been added. Also the “as type” expression notation is redundant after this addition. 
 
 We will have fewer library functions and fewer expression syntaxes after this, without loss of functionality.
 
-Parsing functions, as generated by types here, have parameters. The first and only positional parameter is what they will parse. The other parameters will be keyword parameters to provide options to the parse, such as \`allowAmbiguity\` and \`src\` and to provide contextual data to data-dependent parsers (when they are added).
+Parsing functions, as generated by types here, have parameters. The first and only positional parameter is what they will parse. The other parameters will be keyword parameters to provide options to the parse, such as `allowAmbiguity` and `src` and to provide contextual data to data-dependent parsers (when they are added).
 
 ## Motivation
 
-* There are several ways of calling a parser right now in Rascal, none of them unique in terms of features, just different in syntax. It’s unnecessary. E.g. parse functions, read functions like readTextValueString, the \[AsType\] syntax, pattern matching. Is there more?  
+* There are several ways of calling a parser right now in Rascal, none of them unique in terms of features, just different in syntax. It’s unnecessary. E.g. parse functions, read functions like readTextValueString, the [AsType] syntax, pattern matching. Is there more?  
   * Each has its own syntax  
   * Each has its own way of dealing with exceptions  
   * Each has its own configurability  
@@ -40,25 +40,25 @@ Parsing functions, as generated by types here, have parameters. The first and on
 
 No new syntax is necessary for the new feature:
 
-* syntax Expression \= Expression “(“ {Expression “,”}\* “)” // callOrTree exists already  
-* syntax Expression \= “\#” Type // type reification exists already
+* `syntax Expression \= Expression “(“ {Expression “,”}\* “)” // callOrTree exists already`  
+* `syntax Expression \= “\#” Type // type reification exists already`
 
 The new semantics is for the callOrTree syntax, statically we also allow these applications now:
 
-* \<type\[\&T\] type\> ( loc input, bool allowAmbiguity \= false )  
-* \<type\[\&T\] type\> ( str input, loc src \= |unknown:///|, bool allowAmbiguity \= false )  
-* Both expressions return a value of type \`\&T\` (as instantiated) when successful, or they throw a syntaxError or a validationError exception value (see below)
+* `<type[&T] type> ( loc input, bool allowAmbiguity \= false )  `
+* `<type[&T] type> ( str input, loc src \= |unknown:///|, bool allowAmbiguity = false )`  
+* Both expressions return a value of type `&T` (as instantiated) when successful, or they throw a syntaxError or a validationError exception value (see below)
 
 Semantically, the parser which will be called switches on the kind of type and the kind of input:
 
-* \[builtin, text\] For builtin types such as list, int, applied to a text file or string, the Rascal text value parser will be called;  
-* \[builtin, bin\] For builtin types applied to a binary serialized file, the Rascal binary value parser will be called  
-* \[data, text\] the Rascal text value parser will be called, and the value will be validated against the abstract syntax definition defined by the given reified type. Note that this gives rise to programmatically constructed abstract grammars which are used as parsers.  
-* \[data, bin\] the Rascal binary value parser will be called and the result will be checked against the expected top-level type  
-* \[syntax, text\]  
+* [builtin, text] For builtin types such as list, int, applied to a text file or string, the Rascal text value parser will be called;  
+* [builtin, bin] For builtin types applied to a binary serialized file, the Rascal binary value parser will be called  
+* [data, text] the Rascal text value parser will be called, and the value will be validated against the abstract syntax definition defined by the given reified type. Note that this gives rise to programmatically constructed abstract grammars which are used as parsers.  
+* [data, bin] the Rascal binary value parser will be called and the result will be checked against the expected top-level type  
+* [syntax, text]  
   *  if the input does not start with “appl(” then a generated parser will be called to parse the text using the given non-terminal/grammar in the reified type  
   * If the input is an already serialized parse tree, the code will use the values reader and validate if the top-type is indeed the expected non-terminal or throw a validation exception  
-* \[syntax, bin\] the input is an already serialized parse tree in binary input, the code will use the values reader and validate if the top-type is indeed the expected non-terminal or throw a validation exception
+* [syntax, bin] the input is an already serialized parse tree in binary input, the code will use the values reader and validate if the top-type is indeed the expected non-terminal or throw a validation exception
 
 Exceptions thrown by the new expression: