4 ms·

I tried swipl prolog and enjoyed it but poor PostgreSQL support scared me away. Any prolog developers have any advice? I really like prolog but need an implemen

I tried swipl prolog and enjoyed it but poor PostgreSQL support scared me away. Any prolog developers have any advice? I really like prolog but need an implementation with good db support for specifically Postgres but haven’t found anything.

YeGoblynQueenne 8y ago
You don't need SQL if you have Prolog. Prolog itself can store and retrieve all your data, except that data is also your program at the same time. For instance, see: Can I replace a LAMP stack with SWI-Prolog? http://www.swi-prolog.org/FAQ/PrologLAMP.html http://www.swi-prolog.org/FAQ/PrologLAMP.html
- justbaker 8y ago
  This is a really great answer, thank you.
  - YeGoblynQueenne 8y ago
    Cheers. Note also that you can relatively easily move all your SQL tables to Prolog by exporting them as text files with Prolog facts of the form: <table_name>(<column 1, row 1>, <column 2, row 1>, ...., <column n, row 1> ) ... <table_name>(<column 1, row m>, <column 2, row m>, ...., <column n, row m> ) So each table becomes a predicate with the table name as its predicate symbol ("functor" in Prolog), the number of the columns in the table as its arity (the number of arguments of the predicate) and where each row of the table is a separate clause of the predicate. Many tables exported this way will not be necessary any more, particularly those ubiquitous tables used to map other tables' keys between them ("Customer_ID_Ticket_Id" etc) and in most cases primary key fields will no longer be necessary and so on- but you can move all your data to Prolog, with very little change, is what I'm trying to say. Mer' Christmas :)
    - justbaker 8y ago
      Nice! That gives me faith for using it for my personal projects. I enjoyed erlang when I programmed in it in my fledgling days and I like the tenseness of the prolog-influenced languages. Having a very easy way to port to a platform(or off, sometimes) is certainly a valid concern of mine when choosing my tooling. Merry Christmas to you as well :)
- marcosdumay 8y ago
  That raises the questions of how competent are the atomicity of changes, persistence, and speed and memory optimizations implementations of your Prolog interpreter? And, since those are not usual goals of an interpreter, I would guess "not very competent" for at least the first two with high certainty. It also raises the question of whether Postgres has a good Prolog plugin. This one looks more likely to be useful.

YeGoblynQueenne 8y ago

You don't need SQL if you have Prolog. Prolog itself can store and retrieve all your data, except that data is also your program at the same time. For instance, see: Can I replace a LAMP stack with SWI-Prolog? http://www.swi-prolog.org/FAQ/PrologLAMP.html http://www.swi-prolog.org/FAQ/PrologLAMP.html

justbaker 8y ago
This is a really great answer, thank you.
- YeGoblynQueenne 8y ago
  Cheers. Note also that you can relatively easily move all your SQL tables to Prolog by exporting them as text files with Prolog facts of the form: <table_name>(<column 1, row 1>, <column 2, row 1>, ...., <column n, row 1> ) ... <table_name>(<column 1, row m>, <column 2, row m>, ...., <column n, row m> ) So each table becomes a predicate with the table name as its predicate symbol ("functor" in Prolog), the number of the columns in the table as its arity (the number of arguments of the predicate) and where each row of the table is a separate clause of the predicate. Many tables exported this way will not be necessary any more, particularly those ubiquitous tables used to map other tables' keys between them ("Customer_ID_Ticket_Id" etc) and in most cases primary key fields will no longer be necessary and so on- but you can move all your data to Prolog, with very little change, is what I'm trying to say. Mer' Christmas :)
  - justbaker 8y ago
    Nice! That gives me faith for using it for my personal projects. I enjoyed erlang when I programmed in it in my fledgling days and I like the tenseness of the prolog-influenced languages. Having a very easy way to port to a platform(or off, sometimes) is certainly a valid concern of mine when choosing my tooling. Merry Christmas to you as well :)
marcosdumay 8y ago
That raises the questions of how competent are the atomicity of changes, persistence, and speed and memory optimizations implementations of your Prolog interpreter? And, since those are not usual goals of an interpreter, I would guess "not very competent" for at least the first two with high certainty. It also raises the question of whether Postgres has a good Prolog plugin. This one looks more likely to be useful.