bsc-projects-18.html
changeset 553 72bc90a6df8c
parent 552 4e2884c34f46
child 554 7f3b9ab6f71a
equal deleted inserted replaced
552:4e2884c34f46 553:72bc90a6df8c
   172   module, that would obviously give you a head-start with this project.
   172   module, that would obviously give you a head-start with this project.
   173   </p>
   173   </p>
   174 
   174 
   175 <li> <H4>[CU5] Grammars and Derivative-Based Parsing Algorithms</H4>
   175 <li> <H4>[CU5] Grammars and Derivative-Based Parsing Algorithms</H4>
   176 
   176 
       
   177 <p>
       
   178 Parsing is an old nut. Generations of software developers need to do parsing of data or text.
       
   179 There are zillions of links, tools, papers and textbooks about parsing. One particular
       
   180 <A HREF="https://dickgrune.com/Books/PTAPG_1st_Edition/BookBody.pdf">book</A> contains something
       
   181 like 700 different algorithm, nicely analysed and described. Surely, parsing must be a solved problem. Or is it? 
       
   182 Laurie Tratt has a blog <A HREF="https://tratt.net/laurie/blog/entries/parsing_the_solved_problem_that_isnt.html">post</A>
       
   183 about <i>Parsing: The Solved Problem That Isn't</i>. IMHO parsing is still a wide open field and not solved at all.
       
   184 PEG parsing, error reporting, error correction, runtime to name just a few are aspects that seem to cause headaches
       
   185 to developers, and to researchers.</p>   
       
   186 
       
   187 <p>
       
   188 A recent <A HREF="https://www.cl.cam.ac.uk/~jdy22/papers/a-typed-algebraic-approach-to-parsing.pdf">paper</A> 
       
   189 (not even published yet) follows an idea for regular expressions: it adapts the notion of 
       
   190 derivatives of regular expressions to grammars. The idea is to implement in a functional programming language
       
   191 the parsing algorithm proposed in this paper and to try it out with some sample data.
       
   192 </p>
       
   193 
   177 <B>Literature:</B> <A HREF="https://www.cl.cam.ac.uk/~jdy22/papers/a-typed-algebraic-approach-to-parsing.pdf">paper</A>  
   194 <B>Literature:</B> <A HREF="https://www.cl.cam.ac.uk/~jdy22/papers/a-typed-algebraic-approach-to-parsing.pdf">paper</A>  
   178 
   195 
       
   196 <B>Skills:</B> See [CU1].
       
   197 
   179 <li> <H4>[CU6] Webassembly Interpreter / Compiler</H4>
   198 <li> <H4>[CU6] Webassembly Interpreter / Compiler</H4>
       
   199 
       
   200 <p>
       
   201 Webassembly is a recently agreed standard for speeding up web applications in browsers. In this 
       
   202 project the aim is to implement an interpreter or compiler for webassembly. There are already
       
   203 <A HREF="https://github.com/WebAssembly/spec/tree/master/interpreter">reference interpreters</A>,
       
   204 but people take different views, for example implement a 
       
   205 <A HREF="https://groups.google.com/forum/#!topic/comp.lang.forth/CvNrP_AOmmw">Forth</A> language on top of webassembly. 
       
   206 What is good about webassembly is that is a rather simple format, which can be generated quite
       
   207 easily, unlike Java class files, which need some head-standing when you generate them. 
       
   208 </p>
   180 
   209 
   181 <A HREF="https://github.com/WebAssembly/spec/tree/master/interpreter">Reference Interpreter</A>  
   210 <A HREF="https://github.com/WebAssembly/spec/tree/master/interpreter">Reference Interpreter</A>  
   182 
   211 
   183 <li> <H4>[CU2] A Compiler for a small Programming Language</H4>
   212 <li> <H4>[CU2] A Compiler for a small Programming Language</H4>
   184 
   213