51–60 of 74 posts
Have you learned about definite clause grammar yet? Once you do, you may be tempted to rewrite your parser, because it's a much more elegant way of constructing parsing rules.
Earlier quoted context omitted.
I'm repeating what most users told me. This is a new one on me. Care to elaborate?
A common Prolog programming pattern involves creating a partially instantiated term (a "structure" with "holes") and filling in the details later. This can improve expressivity, composability, and performance. For example, this code: L = [_,_,_], maplist(p, L) enumerates all three-element lists whose members satisfy the predicate p. This technique is impossible in Mercury because it does not allow terms with holes. O…
James, check out Mercury next as it's a faster, better Prolog with some industrial use. https://mercurylang.org
https://en.wikipedia.org/wiki/Prince_(software)
It's a software to generate PDF from XML and HTML content with CSS.
In one of my first jobs out of college, I got assigned to figure out how to make the Tivoli Enterprise Console do something useful. They gave up on the IGS guys and picked me because I took a class that used Prolog in my sophomore year. IBM bundled some ancient prolog dialect (copyright 1991 iirc) and the product was a mess. But it was a great time... a coworker and I came up with a way to persist facts to DB2 and de…
The embedded Prolog was ProLog by BIM, from BIM Systems, which was the Belgian-based competitor to a US-based company called Quintus, in Mountain View; both offered high-end Prolog systems for Unix. One of the things that ProLog by BIM had was the ability to have Prolog use Oracle or Sybase databases as if they were Prolog's own native database (Spooky23, if you see this, I was wondering if that helped you use DB2 in…
Those BIM features were unknown to us as we had no BIM manuals. We took some open source code in a mailing list that let you dynamically load shared libraries. That's how we interacted with the DB2 client, and we also did a similar thing with Perl so the admins could do some work for us.
The IBM macro stuff was mostly there to power their (Motif based) rule builder GUI and was pretty limited unless you pre-processed events upstream and spoon fed it. That's why the IGS guys struggled -- they were certified against the base product (and had minimal experience beyond installing the thing) and the salespeople were aspirationally selling whatever one of the big financial services places did with the product.
It's been 15 years so I'm hazy but I'm pretty sure I tossed most of the macros that shipped with the product. It was a really fun gig and I learned a lot from it.
Earlier quoted context omitted.
A common Prolog programming pattern involves creating a partially instantiated term (a "structure" with "holes") and filling in the details later. This can improve expressivity, composability, and performance. For example, this code: L = [_,_,_], maplist(p, L) enumerates all three-element lists whose members satisfy the predicate p. This technique is impossible in Mercury because it does not allow terms with holes. O…
Thanks for the explanation. I agree the example is concise and powerful. I'll run it by Mercury users or developers to see what their answer to that is. They might have a good solution or maybe not due to language's design.
Out of interest, in what sort of function do you talk to Mercury users and developers if you don't use it yourself?
Earlier quoted context omitted.
>(Yes, a language to make languages.) Are there any other languages that are mainly designed with the goal of making it easier to make other general-purpose languages (as opposed to languages for DSLs or parser generation etc.)? I know that generally many languages are written in C or compile to C, and that Lisp can also be used to make other languages or sub-languages. But asking about languages (mostly) dedicated f…
Lisp. Clojure for instance has a built in logic language called miniKanren
https://en.wikipedia.org/wiki/MiniKanren
From that page:
"There are implementations of miniKanren in Haskell, Racket, Ruby, Clojure, and Python. The canonical implementation is an embedded language in Scheme. The Clojure core.logic library was inspired by miniKanren."
The name kanren comes from a Japanese word for "relation".
Earlier quoted context omitted.
My understanding is that there's a very limited amount of research going into Prolog so it ends up being incredibly slow for larger tasks. And a lot of it's functionality can be done via standard SQL so there's not a ton of use cases for it.
Prolog implementations are still the fastest, most researched, and most practical logic languages out there. I don't know what the alternative would be, besides something fundamentally less powerful, like datalog or sql. SQL only gets you so far. For example, you can't do something as straight forward as logic based arithmetic in SQL.
Agree with you on the SQL part and was just making the point that a lot of the intro Prolog examples can be done in SQL.
Have you learned about definite clause grammar yet? Once you do, you may be tempted to rewrite your parser, because it's a much more elegant way of constructing parsing rules.
I have not learned about that, but I'm very interested now. Before I go and google it, do you have a specific place you'd recommend I go to learn about it?
Earlier quoted context omitted.
Thanks for the explanation. I agree the example is concise and powerful. I'll run it by Mercury users or developers to see what their answer to that is. They might have a good solution or maybe not due to language's design.
You're welcome! I last looked at Mercury about 3 years ago, and I vaguely remember partial instantiation being documented as an eternal low-priority future feature. Maybe there's been progress... or maybe they'll say this is less useful than Prolog weenies like to claim ;-) Out of interest, in what sort of function do you talk to Mercury users and developers if you don't use it yourself?
I do have a slight tie-in to my field where I keep logic systems in my peripheral in case they become useful for (a) executable specifications, (b) connections to provers like Milawa, (c) easier formal verification, or (d) commercial deployment in a good one that almost skips the coding phase by keeping code close to specs. Mission Critical IT claims to use Mercury for (a) and (d) with a finance developer linked here a while back using Prolog for whole app. Got easy extensions and fixes as result. So, these conversations might have benefit later.
Earlier quoted context omitted.
How so? I mean, there are logic libraries available for python to be sure. But the "set class and comprehension syntax" are two features only tangentially related to logic programming. Using them alone doesn't get you inference, or even unification.
Inference is straightforward using dictionaries, membership-testing, and set methods, like subset, superset, disjoint, union, intersection, and difference. Python can't do a conditional assignment as nicely as Prolog's unification, but you can get similar behavior via the application of predicates in comprehensions and using set methods. I'm not saying Python is equivalent, but simply that you can get some of Prolog'…
In order to follow this through, you would need to separate all of search code (i.e. the comprehensions) from the declaration of facts and rules. If you were successful in doing so, you will have made a basic logical inference engine in Python.
Consider one of the queries described in the family tree example: "M is the mother of X if she is a parent of X and is female"
In Prolog this might look like:
mother(X, M) :-
parent(X, M),
female(M).
1) Who is the mother of sophia? : mother(sophia, X).
2) Who is sophia the mother of? : mother(X, sophia).
3) Which mothers have male children? : mother(M, X), male(M).
The question is, how would you define the `mother` relation using comprehensions in a way that is agnostic to the specific questions that will be asked? You would inevitably need to write different loop for each variant of the question. The trick is to write an engine that, given a query, automatically generates the comprehensions required to find the answers. It isn't an easy problem at all.
To make this even clearer, consider your claim that the tools in part 4 are trivial in python, because they are all built-ins. But this is not true at all! Python's built-ins are one-way functions, rather than relations. In python I can ask "what is the sum of the elements in this list?" but I can't as easily ask "what is a list with 30 unique integer elements that sum to 100" To do this in python you would need to put some thought in to how you would generate lists using nested loops so that all of the properties were satisfied. In Prolog you just list the search criteria and it does the work for you:
size(L, 30),
unique(L),
sum(L, 100).