Hi all, I’m Jan and I got started with Prolog fairly recently to learn more about logic programming. I’m a .NET developer by profession so I was immediately intrigued by the idea of creating an MQI client for C# so that I could query Prolog files or do some ad-hoc stuff to build integrations in a language I’m familiar with while also making sure to maintain the integrity of the target ecosystem.
I’ve noticed, however, that the JSON output for MQI leads to a few ambiguities (these are just the ones I’ve found during testing):
- no distinction between atoms, quoted atoms and strings
- no distinction between atoms and variables and strings (requires checking for capitalization)
- a dictionary containing only the keys “functor” and “args” (with a list value) is indistinguishable from a compound term
These are just the ones I’ve run into while developing the client. Perhaps there exist more subtle ambiguities that I’ve missed since I’m not familiar enough with the language, but if I understand correctly, atoms and compound terms are ubiquitous in Prolog, so it is rather painful that the spec isn’t more precise in those areas.
Since I wasn’t sure how to handle these cases, I asked Claude and ChatGPT for guidance, and they both recommended using reification before quering MQI, so that MQI returns the solutions as primitive type compounds (e.g. `reify(Float, float(Float) :- float(Float)`).
It seems like that exact solution could be implemented on the server’s end, however. It would be a breaking change, but it would make the spec a lot more clear.
An alternative solution, though I am not familiar enough with the language to confidently propose this, would be to add an “type” key for terms that represent some kind of primitive type. Compared to the full compound term approach, adding just one key-value pair would not make the payload grow as dramatically, but it would still make the spec more clear.
I’m not sure if this is the right category for this topic. I know specs aren’t easy to change, so if the suggestions don’t end up making it, I would also be more than happy to hear more robust workarounds or other solutions to resolve these ambiguities on the receiver’s end.