A snag I hit in my blog tutorial was text needed to be checked for single quotes before inserting them into an SQL database, and if so the single quotes needed to be escaped SQL-style.
Did you write test cases for it and check the boundary conditions? If so and it works then move on. To quote Donald Knuth.
" premature optimization is the root of all evil (or at least most of it) in programming .
Remember you can always update it later. Most people who read your blog are probably more interested in seeing the dots connected than seeing perfect shinny dots.
I’m a big fan of literate programming and test driven development, and hope to write a follow up howto on those for SWI Prolog at some stage. (I’m not aware of good ways of doing these for web development, other than eyeballing the error messages in the browser if something is broken).
A reason I’m working through the old Udacity course again and re-implementing it in SWI Prolog is it avoids the common tutorial problem of sticking to examples a given language is good at and there are often repeated solutions for, and there was no way of avoiding making ASCII art not make odbc_query choke without solving the escaping single quote problem in a way which I assume is a common problem in Prolog.
I only realised Steve Huffman’s genius in picking that project while I was working through it.
The final check is probably not needed, but in all my initial code I find that having extreme type checking finds bugs I would have never seen otherwise. Latter when the code is passing all of the test and humming along, most to all of the type checks can be commented out or removed all together.
At some point you use ‘action(/)’ in one of your forms. I found it in unit2. That’s not needed. In fact it invokes the root folder, which is not always desired behavior.
Thanks @mgondan1, I need to refactor the tutorial soon. At the moment, I’m redoing it in Erlang which I hope to put on github soon. I find Erlang and Prolog nicely complimentary.
Neither is IMO the first. split_string/4 does the type checking for you. Less code is easier to read and uses less resources (time and space). Runtime type checking is typically best left to automatic instrumentation such that it doesn’t clutter code and can be disabled in a final version. Using (type) property declarations you also open the path to static analysis (with all its problems).
There are a number of packages to achieve that. At some point there should be proper default infrastructure. For now, my heuristics are
If predicates that do type checking are called that do most of the job for free, do not add type checks.
Add the to public predicates that may easily fail when used with the wrong type given some likelihood that the predicate is easily misused.
We have seen many type systems passing by in the Prolog community. Prolog is a bit of a nasty beast though. Net to classical types we have instantiation, multiple modes and the search pattern for a solution that may make certain subtrees of the search tree only accessible with some restricted type or the negation thereof. You can solve that by restricting the language, but then you cannot call it Prolog anymore. You can also look for an annotation format that can describe this complexity. Ciao did probably the most relevant and complete work here. The result is rather complex to use and proving type correctness quickly becomes unrealistic.
I’m not saying there is no solution. Recent developments for type systems in dynamically typed languages (another issue) may help. Its not easy though.