3 ms·
This is a really great answer, thank you.
by justbaker 8y ago
This is a really great answer, thank you.
- YeGoblynQueenne 8y agoCheers. 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 agoNice! 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 :)