louise

k using Lisp, this thing does something close using Prolog. [1] https://en.wikipedia.org/wiki/Eurisko

and when first EXEC produces something for second to execute upon ( \alpha \beta (\beta -- \gamma (\alpha \gamma -- \theta) -- \theta). One can argue that second type of EXEC EXEC subsume first one, if greek-letter-named-stack-parts are allowed to be empty. Still it shows that typing Forth, at the very least, needs unification on the Peano's arithmetic level, implementing deduction from length zero to unbounded length. So, in my opinion, for LLM to dependably combine typed Forth/concatenative definitions, it needs to call external tool like Prolog to properly deduce type(s) of the sequence of Forth's (or concatenative language's) definitions. And here we enter a realm interesting in itself. Here it is: https://github.com/stassa/louise This is a Prolog system to learn programs in polynomial time. For one example, it can one-shot-learn a grammar, without being "trained" on millions of samples. So, should one use a LLM that either needs a paid access or just slow to run, or freely go where "old school" systems like Eurisco [1] and Cyc went? [1] https://en.wikipedia.org/wiki/Eurisko Eurisco demonstrated superhuman abilities in 1982-83. It also demonstrated knowledge transfer at the time, where rules from VLSI place-and-route algorithms were used to design winning Traveler TCS fleet.

get to grips with it which you just don't get in undergrad (not least because many tutors themselves aren't that deeply knowledgeable in the subject). I note also that you seem to have been introduced to Prolog in terms of its vaunted declarative qualities: "you just write the rules". That's probably the worst lie one can tell to students and the worst possible way to introduce Prolog, because, as you found out, Prolog just doesn't work that way. For example, back in my undergrad, I only learned about the "declarative paradigm" much later on and even then I thought it was more of a gimmick, the kind of argument people reach for when they try to convince others to be excited about the same things they're excited. This kind of argument is supposed to go beyond aesthetics, but it fails to do so. For example, why is declarative programming better than procedural? It isn't. It's just a matter of taste. The first thing I paid attention to about Prolog was "automated theorem proving", which was what blew my mind. I had just noticed the way manual theorem proving proceeds in a very mechanical manner and was thinking it should be possible to write a program to do it, when I found out someone had done it, for real, and much better than I ever could. I don't think that's aesthetics. It's a real, and distinct, capability, that you don't find e.g. in C or Haskell. How important it is, that's again a personal matter. For me, plenty. For others, not so much. De gustibus etc. The right way to introduce Prolog is the long way around, starting with propositional logic, then FOL, then logic programming, then Resolution, and then only at the end introducing Prolog and other logic programming languages. The way Prolog is taught now, it just doesn't work and everyone leaves university without understanding a thing about it. I can't give a "serious example" of using Mercury or Curry because I have only checked them out once or twice and don't have experience with them. I don't have anything against them, to be clear, as I don't have anything against Datalog. I prefer Prolog because it's more mature, and its implementations more feature-rich. SWI-Prolog in particular is bedecked with libraries like a swiss army knife and its maintainer is a programming super-hero. But if you like Mercury then you could possibly help with its development, which I understand has slowed down for lack of interest, which is a big shame. On meta-interpreters, I use one all the time. The Inductive Logic Programming system that I created during my PhD is based on an inductive, second-order Prolog meta-interpreter: https://github.com/stassa/louise You'll find the early version of that meta-interpreter in https://github.com/stassa/louise/blob/master/src/vanilla.pl A new version, decoupled from any specific learning system, is in a private repo. Let me know if you're very very interested. A write up is here: https://hmlr-lab.github.io/pdfs/Second_Order_SLD_ILP2024.pdf >> Prolog can get stuck in a branch of the search tree that cannot lead to a solution. There's more ways to execute Prolog than DFS so that you don't get stuck in loops. Obviously there'll always be infinite proof branches because Church-Turing. I'm not sure you fully appreciate that?

l program synthesis systems are trained on examples that consist of pairs of (programming-task, program-solving-the-task). Another way to see the difference between Inductive Programming systems and conventional machine learning systems used for program synthesis is that Inductive Programming systems learn by solving problems rather than from observing solutions. The advantage is that, in this way, we can learn programs that we don't know how to write (because we don't have to generate examples of such programs) whereas with conventional machine learning we can only generate programs like the ones the system's been trained on before. Another advantage is that it's much easier to generate examples. For instance, if I want to learn a program that reverses a list, I give some examples of lists and their reverse, e.g. reverse([a,b,c],[c,b,a]) and reverse([1,2,3],[3,2,1]) whereas e.g. an LLM must be trained on explicit examples of list-reversing programs; like, their source code. IFP and ILP systems are also very sample efficient, so they only need a handful of examples, often just one, whereas neural net-based systems may need millions (no exaggeration- can give a ref if needed). The disadvantage is that learning a program usually (but not always - see Louise, above) implies searching a very large combinatorial space and that can get very expensive, very, very fast. But, there are ways around that.

fast solutions thanks to better heuristics, not thanks to more data (that are useless to them anyway). That's a real advance. I still would like a quantification of the "vast trim" btw. Numbers, or it didn't happen.

ou can find online about MIL, but I recommend (PLUG ALERT) the documentation of the MIL system I created for my doctoral thesis as a starting point: https://github.com/stassa/louise I recommend that as a starting point because it's written for people who are familiar with logic programming, but not necessarily ILP. Anyway, plug over. I think MIL is an exciting new development that has of course gone under the radar of the logic programming community at large.

o write that "pure" version of the Ackermann-Péter function not because I'm so full of myself I think it's "elegant" but because it is simple, and thanks to its simplicity I could then get my ILP system, Louise, to learn it from a single example: https://github.com/stassa/louise/blob/master/data/examples/a... The is/2 version would be much harder to learn, because of the more complex structure. Although I think Louise can do that too. Btw, I got Louise to learn the Function because I was challenged to do it by one of the examiners in my viva, who figured the Function's furious combinatorial complexity makes it unlearnable. That's right, but Louise can get around that because it can learn recursive programs with arbitrary structure from a single example, so it doesn't have to be trained on any example that triggers the Function's combinatorial fury. In any case, Ackermann is a toy function only really useful to make a point about recursion, and that's exactly how I use it also. Who cares if it blows up with n = 2, m = 4, or with n = 5, m = 6? It blows up quickly anyway. That's the whole point. So, your comment above is very stream-of-consciousness and I wonder what motivated you to write such a mad rant of the internets. I guess you must be really passionate about the subject you discuss. If so, I understand. You are not alone :) No, really, I generally agree with you. I asked above what is "usefulness" because for me Prolog is useful and I don't understand why anyone would say it isn't. Reading your other comment in the thread, I got the impression you would agree with me on that. But it's not about agreement. Aye, the night is long and full of errors and we must somehow deal with the dirty, dirty real world. Personally, I'm happy with that. But I do like my tools to also be nice to look at and I find that when I can make them so, they also tend to work better. For example, cleaner, better commented code, is easier to read and maintain. I mean, duh. In any case, in my mind, a well-made tool is a thing of beauty anyway you look at it. Re: "quality of life", well yea, that. If you were to look at my Louise, I think you'd find that I've gone out of my way to make it into a system that people can used. I'm totally inspired to do that by SWI-Prolog, btw. So for example, Louise has logging facilities up the wazoo and so everytime someone tries to use it and it breaks, they send me a nice, friendly dump of their logs, and then I can trudge through them and help my user. Because I want to help my user. I wish people sent me more bug reports, but I guess the majority find that something breaks and they don't bother to tell me. Oh mon dieu, la cruelle tourmente. As another example, I spent considerable effort to make sure that Louise's "metarules" (second-order background knowledge) are easy to read and use. For that purpose there's three metarule formats that Louise's pretty-printer can produce. One is the internal representation of the metarule that's useful for debugging, one is the user-friendly format where metarules are declared at the user-level and a final one is the formal notation, with quantifiers, used in the literature, so users can directly relate the metarules they use to a paper they read. Here's what that looks like ("chain" is the friendly identifier of that particular metarule): ?- print_metarules(expanded, chain). m(chain,P,Q,R):-m(P,X,Y),m(Q,X,Z),m(R,Z,Y) true. ?- print_metarules(user_friendly, chain). configuration:chain metarule 'P(x,y):- Q(x,z),R(z,y)'. true. ?- print_metarules(quantified, chain). (Chain) ∃.P,Q,R ∀.x,y,z: P(x,y)← Q(x,z),R(z,y) true. By contrast, if you look at the original Meta-Interpretive Learning system, Metagol (https://github.com/metagol/metagol), this is what "chain" looks like: metarule([P,Q,R], [P,A,B], [[Q,A,C],[R,C,B]]). % chain If I understand your comments about "quality of life" work correctly, then that's pretty much what I always try to do and what most people in academia never do. Guess what, I'm out of the game now. But, well, at least I tried :)

Tamaki and Sato described it in 1986, I believe: https://link.springer.com/chapter/10.1007/3-540-16492-8_66 But then implementations took a bit to catch up. >> Prolog is deeply unsuited for work, use Clingo instead. Well, that doesn't make sense. ASP doesn't even allow lists, let alone side-effects (you know, like writing to a stream), so what "work" is it that it's better suited for, than Prolog? Also, if I remember correctly, Clingo is not a language but a grounder? It takes a first-order program and grounds the entire Herbrand base into a set of propositions so that a SAT solver can then derive the stable models of the program? Do I have that wrong? Let me say up front that I've never heard a worse idea in my life, and I've heard a few. First of all, that's why ASP can't use lists, or other functions, because then the Herbrand base goes infinite and good luck grounding it. Second, SAT-solving is NP-complete. As I realised recently (https://news.ycombinator.com/item?id=34072923) ASP is an elegant framework for dealing with uncertainty in a purely symbolic manner, with negation as failure and axiomatic, classical negation. But then, why go and mess this elegance up with a dumb propositionalisation approach that loses all the good stuff about first order logic, and that's terminally inefficient to boot? That, I still don't get.