Prolog interpreter in Go(github.com)
github.com
Prolog interpreter in Go
https://github.com/mndrix/golog
6 comments
Thanks for the video, really cool.
Prolog is my favorite example language I use to convey the concept of how different programming paradigms lend themselves to different types of problems. After learning the syntax and mechanics prolog seems like a ridiculous language that was written to win a drunken bet with a philosopher. but given the right problem it feels like using black magic.
Solving Einstein's riddle[1] is trivial in prolog for example. But perhaps only because we know that the answer can be determined from the premises.
1) http://en.m.wikipedia.org/wiki/Zebra_Puzzle
Solving Einstein's riddle[1] is trivial in prolog for example. But perhaps only because we know that the answer can be determined from the premises.
1) http://en.m.wikipedia.org/wiki/Zebra_Puzzle
See also the SWI-Prolog example:
http://swish.swi-prolog.org/example/houses_puzzle.pl
http://swish.swi-prolog.org/example/houses_puzzle.pl
Wow, just last week I was thinking how useful having embedded prolog in Go would have been, for a very particular problems that maps very well in Prolog. I'm super excited by this!
What problems are they? I'm interested in Prolog but never encountered something I thought would be a good fit (or perhaps I'm not thinking about it the right way)
Ditto here. Also excited.
I would love to use this for compiler analysis, I need to research how this can be used with tools/ssa to do whole program logic queries.
Prolog interpreter is unlikely to be able to meet your performance needs although it would be a great ui. Search datalog and bdd and you should be able to find some good research and tools using bdd to support source code analysis related queries.
I thought about using datomic for this before. I've seen a Java based bdd data log tool for pointer analysis. Though it was hard to play with Iirc. I think it would be slow but good for prototypes.
Is this you? https://github.com/achambers16
Either way, email's in my profile. We should talk.
Either way, email's in my profile. We should talk.
Nah, this is me.
https://github.com/andrewchambers
https://github.com/andrewchambers
First of all, this is great work! Hopefully, it will implement the Warren Abstract Machine[1] in the future, since it generally leads to more efficient interpretation. E.g. both SICStus and SWI-Prolog implement a version of the WAM.
[1] https://en.wikipedia.org/wiki/Warren_Abstract_Machine
[1] https://en.wikipedia.org/wiki/Warren_Abstract_Machine
SWI-Prolog implements a variant of the ZIP, not the WAM.
Ah, thanks for correcting me. I seem to remember that the documentation said WAM.
The title of the repo is spells "interpreter" correctly, so this submission's title should be fixed.
Similarly it spells "Go" correctly :)
tl;dr - I'm upset because the raison d'etat for Go's name doesn't exist.
Correct, no -- practical, probably. No matter how many gophers swear that {searchterm} + go returns just as good of results as {searchterm}+golang, it just isn't true.
Maybe I'm just bitter because the reason Go was named Go was because -- and obviously I'm paraphrasing here... "we thought Oogle would be a really cool name for a debugger."
Years later, here I am stuck searching {some search term} + GOLANG and step debugging with GDB.
The worst part though is hearing people tell me, "Oh you know what, I realize how powerful printline statements and unit tests are for debugging! I don't even miss a debugger!" Or-- "have you tried GDB? Go Supports GDB! I haven't used it -- but it exists!" GDB is a god damn hate machine. And the chorus of "print statements are good enough" is motivated reasoning at its finest.
Correct, no -- practical, probably. No matter how many gophers swear that {searchterm} + go returns just as good of results as {searchterm}+golang, it just isn't true.
Maybe I'm just bitter because the reason Go was named Go was because -- and obviously I'm paraphrasing here... "we thought Oogle would be a really cool name for a debugger."
Years later, here I am stuck searching {some search term} + GOLANG and step debugging with GDB.
The worst part though is hearing people tell me, "Oh you know what, I realize how powerful printline statements and unit tests are for debugging! I don't even miss a debugger!" Or-- "have you tried GDB? Go Supports GDB! I haven't used it -- but it exists!" GDB is a god damn hate machine. And the chorus of "print statements are good enough" is motivated reasoning at its finest.
Fixed.
[1] https://www.youtube.com/watch?v=G_eYTctGZw8