I had always heard of Prolog as being obscure and overly academic. It's popped up a little bit recently however - the last place I heard of it in use is in the recently launched TerminusDB https://github.com/terminusdb?language=prolog
I had always heard of Prolog as being obscure and overly academic. It's popped up a little bit recently however - the last place I heard of it in use is in the recently launched TerminusDB https://github.com/terminusdb?language=prolog
Both Haskell and Prolog seem to run on a school-year cycle where search interest peaks a little before the end of the semester. Prolog's cycle is significantly more pronounced, suggesting the interest is indeed purely academic. Whereas Rust has been growing steadily and shows little seasonality.
I'd say it's random chance, given X million programmers and Y million articles there's always somebody who will see a lot of Z topic.
Terminus in particular seems to be an extension of work Gavin did during his postdoc, in particular the Dacura stuff mentioned here: http://aligned-project.eu/open-source-tools/. He deleted the DQS repository for some reason but there's a mirror here: https://github.com/bozicb/dacura-1.
By inflating the search results they'll encourage the competition to spend inordinate amounts of time learning cat theory and trying to get the compiler to understand their code. In the mean time they'll hack it together in Perl.
Sorry for the inappropriate about at humour, I couldn't resist.
http://wadler.blogspot.com/2015/04/prime-minister-of-singapo...
He is already quite good with C++
https://arstechnica.com/information-technology/2015/05/prime...
Other than that, a lot of it is just automating chores — booking my office hour appointments, maintaining sayit.pdis.nat.gov.tw (part of the radical transparency protocol visit.pdis.tw), etc.
Non-work-related projects such as moedict.tw and Hackage/CPAN modules are mostly in maintenance mode, with occasional releases based on pull requests from the community.
That's not to say that Haskell isn't used in China; there is a visualization group in Didi (Chinese Uber) that uses it, Haskell/FP user groups, university classes, etc. But there's no obvious reason that Haskell would have massively shot up in the past 3 days.
foo(X, Y) :-
some_condition(X),
!,
bar(Y, X).
foo(X, Y) :-
baz(X, Y).
to: foo(X, Y) :-
( some_condition(X)
-> bar(Y, X)
; baz(X, Y) ).
and get the same performance and clearer code.There are really very few actually useful uses of the cut in modern Prolog code. But we have no good, free, current teaching materials, so people get stuck learning the old ugly and convoluted ways.
Unfortunately since it's almost impossible to model ideas without stuff like the arrow, cut, or \+ (not) operators, writing actual pure logical Prolog programs that actually do interesting things is supremely difficult.
For example, both versions of foo/2 that are shown above suffer from the same core deficiency: If some_condition/1 has multiple solutions, then they are cut away and not generated at all. Therefore, for the most general query,
?- foo(X, Y).
only a single answer, or a proper subset of all answers one would expect when reading (->)/2 as "implies", may be shown where, under a declarative reading based on first-order logic, there ought to be more.This is problematic because if any concrete solution S is cut off due to this deficiency, we can still force the Prolog system to yield it with:
?- X = S, foo(X, Y).
So, we are in the situation that adding a constraint (X = S) yields a solution that is not shown when the constraint is removed. In other words, a specialized version of the predicate is more general than the original definition. This violates monotonicity, which is an essential property of classical first-order logic, and the basis for declarative debugging approaches that let us reason about the location of mistakes in Prolog predicates.To write good declarative Prolog code that is also efficient, we first need to find and implement the mechanisms that let us express predicates like foo/2 in such a way that they are efficient while retaining their generality as logical relations.
One important building block pertaining to this concrete example was recently found with the new language construct if_/3, described in Indexing dif/2 by Ulrich Neumerkel and Stefan Kral:
https://arxiv.org/abs/1607.01590
With if_/3, we can write foo/2 as:
foo(X, Y) :-
if_(some_condition(X),
bar(Y, X)
baz(X, Y)).
The only requirement for this to work is to have a reified version of some_condition/1, in such a way that we can tell, from the implicit second argument, whether the condition holds or not, while still generating all answers for the most general query.Some predicates are already reified in the library, so we can write for example:
?- X = a, if_(X = a, Y = b, Y = c).
X = a,
Y = b.
which succeeds without leaving choice-points, and that is good for performance. At the same time, we get both answers (X = a and also dif(X, a), i.e., X is not equal to a) on backtracking if we omit the first goal: ?- if_(X = a, Y = b, Y = c).
X = a,
Y = b ;
Y = c,
dif(X, a).
Hence, the predicate retains important logical properties we expect from first-order logic, and this allows declarative reading and debugging based on these properties.To benefit from the true power of Prolog, such constructs must become available in Prolog implementations. For example, currently, the only Prolog system that ships with if_/3 as a built-in feature is Mark Thom's Scryer Prolog, where if_/3 and related predicates are available in library(reif):
https://github.com/mthom/scryer-prolog
https://github.com/mthom/scryer-prolog/blob/master/src/prolo...
Other features that are necessary to make Prolog programs more declarative include CLP(ℤ) constraints, pure I/O, efficient implementation of partial strings as lists of characters etc., all of which are currently work in progress and as of yet only partially available in some Prolog systems. Over time, such features will become more widely available, and then they can be more easily taught and used to obtain Prolog programs that are pure and efficient.
I always felt that the language was more incomplete for having (needing) such an imperative construct in an otherwise entirely declarative design.
The ability to mix in impure features where needed is what makes Prolog practical.
However: I do miss DCGs in every other language I've used. They're so useful that I've come to hate using regexes or even worse: manually parsing lists and strings.
That's a very general statement. The non-logical behavior can be well-contained and unobservable from the outside. For example, the nice and pure if_/3 internally uses both of the non-logical predicates (->)/2 and (==)/2. Yet viewed from the outside it doesn't taint anything.
> And at that point you step back and ask why you're even using prolog.
As I wrote above, because I think even used imperatively it's a very convenient language for expressing matching and transformation of trees. And DCGs are great as well, I agree.
'Logical' is a misnomer, Prolog is really a database query language. Unlike SQL it's not relational and not based on joins, it has tree walking semantics.
That said, without a decent storage/indexing system under the hood it is indeed quite pointless. Nobody wants a 'small data' tiny DB engine in 2019.