Prolog interpreter in Go | Hacker News Reader

Prolog interpreter in Go

github.com

121 pointsImmortalin23 comments

Open articleView on HN

The golog author has a great presentation on using prolog in production.[1]

[1] https://www.youtube.com/watch?v=G_eYTctGZw8

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

See also the SWI-Prolog example:

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!

Ditto here. Also excited.

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)

Some examples: Combinatorial optimization problems, timetabling tasks, reasoning engines, rule-based systems for the medical industry, recommender systems etc.

So dynamic programming?

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.

Nah, this is me.

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

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.

The debugger on plan9, acid, is a work of art.

similarly, mdb on solaris is very powerful.

Fixed.

Reply on news.ycombinator.com