5 ms·

Could you point me to some resources about this sort of thing? I remember hearing about someone implementing transpilation of some subset of C++ to some subset

by tkot 5y ago

Could you point me to some resources about this sort of thing? I remember hearing about someone implementing transpilation of some subset of C++ to some subset of Java using Prolog but I couldn't find the actual code.

pjmlp 5y ago
You can have a look at my mini-Pascal parser, it was a toy exercise for the university almost 30 years ago, and some day I decided to uploaded into github. https://github.com/pjmlp/Analyzer https://github.com/pjmlp/Analyzer
emmanueloga_ 5y ago
Learn Prolog Now! [1] has a chapter on DCGs [1]. 1: http://www.let.rug.nl/bos/lpn//lpnpage.php?pagetype=html&pageid=lpn-htmlse29 http://www.let.rug.nl/bos/lpn//lpnpage.php?pagetype=html&pag...
YeGoblynQueenne 5y ago
Not a tutorial resource, but the following is an example from my degree project, that I wrote back in 2011 (don't judge me, OK? I've improved since then!). My project was a Magic: the Gaterhing expert system that included a rules engine, an AI player and an interpreter for the language on M:tG cards. The interpreter was written using Prolog's DCGs. The project was written in a proprietary Prolog (Win LPA Prolog) and I've had a lot of trouble porting it over to the free SWI-Prolog - you can't run the entire project. But the DCG rules in links I give below more or less work for any Prolog with a DCG module. Anyway, just looking at the grammars in them should help get an idea of DCGs in an application that is a step above trivial. First, this is the main M:tG game language interpreter (the "MGL" interpreter; "MGL" is my own terminology, since the langauge on M:tG cards doesn't have an official name): https://github.com/stassa/Gleemin/blob/master/mgl_interpreter_delivered.pl https://github.com/stassa/Gleemin/blob/master/mgl_interprete... The first two-thirds of the source in the linked file is a grammar of a subset of the M:tG game language as a set of production rules in DCG form. That's already a parser for that subset of the M:tG language, right there in the DCG rules themselves (DCGs are just syntactic sugar for ordinary Prolog clauses so a grammar in DCG form is a Prolog program that can be executed as any Prolog program). The rest of the file implements rule engine functions some of which are called by the grammar, while others act as an interface with the rest of the rules engine. Probably. I don't remember what everything does... The next file is a DCG for M:tG mana costs: https://github.com/stassa/Gleemin/blob/master/mana_grammar.pl https://github.com/stassa/Gleemin/blob/master/mana_grammar.p... This grammar is referenced from the previous source file where the "mana" nonterminal appears. So that's just an example of how you can modularise your code to avoid having all the rules in one big endless file. On the other hand, nothing stops you from making a big ball of mess by interleaving your grammar with the rest of your code. Like all Prolog programs, DCG grammars can be "run backwards" so that a grammar that acts as a recogniser when given an input string, can act as a generator when given no input (Prolog doesn't have clear input and outputs, just variables to be instantiated as the program runs). So with my M:tG grammar above I could generate text for new M:tG cards. To facilitate this I set up the "MGL parser interface" below: https://github.com/stassa/Gleemin/blob/master/mgl_parser_interface.pl https://github.com/stassa/Gleemin/blob/master/mgl_parser_int... The first defined predicate in there, identify_MGL/0 is used to identify the type of an M:tG language expression (given or generated), such as "activated ability", "triggered ability", "static ability" etc. So that's one example how to use a DCG for semantic analysis of a bit of text. As a for instance, you could use my identify_MGL/0 to search for abilities of a certain type (alongside a keyword search) which most search engines don't really let you do. My "parser interface" used it to generate abilities of a given type. Anyway, that's an example of DCGs "in the wild" (though from someone who had no clue what she was doing when she wrote it). I hope it's instructive and I didn't just toot my own horn for no reason!

by tkot 5y ago

pjmlp 5y ago

You can have a look at my mini-Pascal parser, it was a toy exercise for the university almost 30 years ago, and some day I decided to uploaded into github. https://github.com/pjmlp/Analyzer https://github.com/pjmlp/Analyzer

emmanueloga_ 5y ago

Learn Prolog Now! [1] has a chapter on DCGs [1]. 1: http://www.let.rug.nl/bos/lpn//lpnpage.php?pagetype=html&pageid=lpn-htmlse29 http://www.let.rug.nl/bos/lpn//lpnpage.php?pagetype=html&pag...

YeGoblynQueenne 5y ago

Not a tutorial resource, but the following is an example from my degree project, that I wrote back in 2011 (don't judge me, OK? I've improved since then!). My project was a Magic: the Gaterhing expert system that included a rules engine, an AI player and an interpreter for the language on M:tG cards. The interpreter was written using Prolog's DCGs. The project was written in a proprietary Prolog (Win LPA Prolog) and I've had a lot of trouble porting it over to the free SWI-Prolog - you can't run the entire project. But the DCG rules in links I give below more or less work for any Prolog with a DCG module. Anyway, just looking at the grammars in them should help get an idea of DCGs in an application that is a step above trivial. First, this is the main M:tG game language interpreter (the "MGL" interpreter; "MGL" is my own terminology, since the langauge on M:tG cards doesn't have an official name): https://github.com/stassa/Gleemin/blob/master/mgl_interpreter_delivered.pl https://github.com/stassa/Gleemin/blob/master/mgl_interprete... The first two-thirds of the source in the linked file is a grammar of a subset of the M:tG game language as a set of production rules in DCG form. That's already a parser for that subset of the M:tG language, right there in the DCG rules themselves (DCGs are just syntactic sugar for ordinary Prolog clauses so a grammar in DCG form is a Prolog program that can be executed as any Prolog program). The rest of the file implements rule engine functions some of which are called by the grammar, while others act as an interface with the rest of the rules engine. Probably. I don't remember what everything does... The next file is a DCG for M:tG mana costs: https://github.com/stassa/Gleemin/blob/master/mana_grammar.pl https://github.com/stassa/Gleemin/blob/master/mana_grammar.p... This grammar is referenced from the previous source file where the "mana" nonterminal appears. So that's just an example of how you can modularise your code to avoid having all the rules in one big endless file. On the other hand, nothing stops you from making a big ball of mess by interleaving your grammar with the rest of your code. Like all Prolog programs, DCG grammars can be "run backwards" so that a grammar that acts as a recogniser when given an input string, can act as a generator when given no input (Prolog doesn't have clear input and outputs, just variables to be instantiated as the program runs). So with my M:tG grammar above I could generate text for new M:tG cards. To facilitate this I set up the "MGL parser interface" below: https://github.com/stassa/Gleemin/blob/master/mgl_parser_interface.pl https://github.com/stassa/Gleemin/blob/master/mgl_parser_int... The first defined predicate in there, identify_MGL/0 is used to identify the type of an M:tG language expression (given or generated), such as "activated ability", "triggered ability", "static ability" etc. So that's one example how to use a DCG for semantic analysis of a bit of text. As a for instance, you could use my identify_MGL/0 to search for abilities of a certain type (alongside a keyword search) which most search engines don't really let you do. My "parser interface" used it to generate abilities of a given type. Anyway, that's an example of DCGs "in the wild" (though from someone who had no clue what she was doing when she wrote it). I hope it's instructive and I didn't just toot my own horn for no reason!