Thank you for your comments. Just a clarification: I have not seen a Prolog codebase in the wild (you probably have) so obviously I am not aware of the practical issues with Prolog or Logtalk and so on. I did an inventory of the “few code bases I’ve seen” and actually, out of the 4 I was thinking about, 3 were generating SQL and one was just a terrible mess of C++ with a lot of macros. Of the three that were generating SQL, one was PL/SQL, one Groovy (ha!), and one plain old Java.
The reasons for deciding to do it like this ranged from “we are cool and do fancy stuff” to “no one here wants to learn SQL but ORMs are too complicated so let’s roll our own” to “this is the only way I can implement it in a hurry and keep it acceptably efficient; we have to get rid of it eventually”.
In all cases, it boiled down to SQL fragments embedded in the “host” language. Terribly error prone and very tedious to develop. Had to be “maintained” regularly.
Now that I think about it, the common theme here is SQL, not code generation. Not sure.
I meant, literally, what are common problems that are solved nicely using code generation. I tried to list a few of the cases known to me, and I assume that I don’t know much.
On the other hand, with a clear use case in mind, the question moves from the general to the more specific. Common sense (ha!) tells me it becomes easier to notice outstanding problems and come up with a clean solution for that particular case.
Any problems where a DSL is the best solution from a user perspective. For all but the simplest cases (where you have little more than syntactic sugar using operators), code written in a DSL is compiled.
this is a truism. So the “user” is a programmer too, right? Is the same person designing, implementing, and using the DSL? Are they different people? How do I, Boris, or any unnamed programmer, know that a DSL is called for?
Where do we draw the line between “we need another language with its existing compiler and tooling” and “we can embed this?”
Sorry for the multitude of questions. I don’t know what answers I really expect, for now I just hoped someone will expand the list above.
Well, Prolog doesn’t have the OO - Relational mismatch, so it might make sense. Embedding SQL as strings doesn’t. As compiled statements it starts to make more sense. Better would be if someone wrote a good quasi quotation handler for SQL. Then there is that packages CQL developed by SecuritEase. That provides a much more appropriate level for talking to SQL, but the learning curve is a bit steep
There are more interesting things one can do with Prolog
The rule I tend to use is that if it requires a Turing complete programming language then odds are you are programming in a Turing complete programming language and so leave it in the same language, but if you are creating operators and data that do not require a Turing complete language, and will be used very often, then create a DSL.
However if I need a Turing complete programming language and coding it in that language is not simple then I switch languages, e.g. if I am programming something like a device driver I would probably use C over Java or F#.
I need to give it another try. I admit I tried once (I even wrote a walk-through on how to install all the bits and pieces, not trivial) but I gave up. The documentation is not meant to be read by an outsider, and I don’t understand CHR. I just have to stop finding excuses and do it.
Another question altogether (we’ve discussed this before) is that proprietary database extensions and features and versions make this a Sisyphean effort even if you want to support only one vendor. Not sure if it is economically feasible.
PS: I have a sneaking suspicion that people who don’t want to use/learn SQL might show resistance to adopting Datalog and Prolog, too. This is of course just a speculation.
Load library(apply_macros). That provides goal_expansion/2 alternatives for a number of meta predicates. Modeled after YAP. Eventually a more general inline/partial evaluation should do that.
this is a truism. So the “user” is a programmer too, right? Is the same person designing, implementing, and using the DSL? Are they different people? How do I, Boris, or any unnamed programmer, know that a DSL is called for?
Well, Prolog doesn’t have the OO - Relational mismatch, so it might make sense. Embedding SQL as strings doesn’t. As compiled statements it starts to make more sense. Better would be if someone wrote a good quasi quotation handler for SQL. Then there is that packages CQL developed by SecuritEase. That provides a much more appropriate level for talking to SQL, but the learning curve is a bit steep 