I will extend these examples to illustrate other important concepts and techniques in the future.
Also included is a shortened version of the CLP(FD) manual, intended to be used as supplementary lecture material:
https://github.com/triska/clpfd/blob/master/clpfd.pdf
This
PDF explains the most important concepts of library(clpfd)
and contains a short description of common constraints. It is intended to be used as complementary lecture material for a one to two semester Prolog course at the undergraduate level.
I hope you find this useful.
To purity!
All the best,
Markus
On Wednesday, November 4, 2015 at 12:19:09 AM UTC, Markus Triska wrote:
To purity!
--
You received this message because you are subscribed to the Google Groups "SWI-Prolog" group.
To unsubscribe from this group and stop receiving emails from it, send an email to swi-prolog+...@googlegroups.com.
Visit this group at http://groups.google.com/group/swi-prolog.
For more options, visit https://groups.google.com/d/optout.
- For those interested into where logic programming is going, look up computability logic.
- For those interested in software engineering (actual software production), of course declarative is just part of the picture -- questions should be asked incomp.software-eng.
Hi Julio, Markus, others,
Are there concrete use cases where the principles of Pure Prolog conflict with certain Software Engineering principles? I don't see the mutual exclusivity.
- For those interested into where logic programming is going, look up computability logic.Computability Logic is cool. Is it related to CLP(FD) though?
- For those interested in software engineering (actual software production), of course declarative is just part of the picture -- questions should be asked incomp.software-eng.What's this? A newsgroup of some kind probably, but what does it have to do with CLP(FD)?
I'm a bit confused about these last two remarks.
Are there concrete use cases where the principles of Pure Prolog conflict with certain Software Engineering principles?
--
One reason why declarative Prolog constructs are still somewhat overshadowed by impure primitives certainly lies in their affiliation with some performance downsides
Luckily, the situation is becoming much better in that respect.
For example, Ulrich Neumerkel and Stefan Kral have recently put a lot of work into improving the efficiency and usability of pure monotonic branching constructs.
A German version
It is clear that such large increases in expressiveness and declarative power cannot be immediately or fully understood by everyone
Many people will never be able to follow where the pioneers are heading, and that's OK: Stefan and Ulrich
and portability considerations
Are there more data points you can share in order to substantiate your claim that this is indeed becoming 'much' better. I only see a few scattered attempts in this area.
I happen to be able to read German but it would be beneficial for this text to (also) be available in English.
If programming in (Pure) Prolog would in fact pose significant benefits over less declarative languages without introducing too many resource burdens, then there would be a significant benefit that would warent the cost of learning.
I believe Stefan and Ulrich are particularly well equipped to ease the aforementioned educational hurde. Their effort on Stackoverflow is significant.
~10 years ago, SWI-Prolog looked a bit like a logic-inspired version of Fortran when compared with what we have today: It had no rational numbers, no big integers, no copy_term/3, no pure residual goals, a toplevel and a version of time/1 that would silently cut away further solutions, no call_residue_vars/2, no library(pio), no CLP(B), no way to partially evaluate important and powerful meta-predicates (hence people tended to avoid them, using quite low-level coding styles over and over instead), no pure and robust timeout mechanism, no JIT indexing, a severely leaking freeze/2, and was lacking many other features that areintimately related to purity, declarative properties and at the same time efficiency.
Using the Clark completion is the minimum extension that is needed to
get negative information from Prolog programs. The problem is now
that these existence quantifiers exists Y11...Y1k work fine if a positive
query is issued. Prolog can simply proceed in ignoring such quantifiers
I don't think there is much to disagree.
Hi, mine is just a desire and I really do not know exactly what you are talking about.
Sorry, "pure CLP" was misleading. I am thinking about of a "hybrid" Prolog system, where standard arithmetic is *completely* replaced by CLP.
Such as system should understand the following goal: