5 ms·
> The great initiatives consisting of a small group of experts, such as the ISO working group or the Prolog Commons project, with some tweaks that we hope to ha
by tannhaeuser 5y ago
> The great initiatives consisting of a small group of experts, such as the ISO working group or the Prolog Commons project, with some tweaks that we hope to have covered, can be re-invigorated to make stronger progress in the future. However, they may not be enough to bring together a user community that contributes to the language and its growth.
Not wanting to take away from that Festschrift and the wealth of authors covering generations of Prolog programming, but realistically, Prolog Commons contributed very little, was almost entirely ignored, had its last update almost ten years ago, can't be contributed towards, and those things it did add feel distinctly un-Prolog-ish and procedural, such as get_ and put_ primitives for maps.
Also, ISO/IEC 13211-1:1995/Cor.2:2012(E) feels kindof rushed (eg specifying false/0 thereby trivially breaking existing Prolog code such as ILP packages for no reason, insufficient description for subsumes_term/2, introducing call/N and the concept of closures without sufficient precedent, etc.)
- YeGoblynQueenne 5y agoHi, can you please explain how false/0 breaks ILP packages? I'm asking agnostically: I neither disagree nor agree with you. I study ILP, but I can't think of how false/0 would break Aleph, for instance (although truth be told I'm not as experienced with pre-2000 systems). And thanks in advance!
- tannhaeuser 5y agoAleph uses rules of the form false :- whatever(x) to represent negative examples, and will load those from a file derived from the project name with ".n" suffix and then assert these clauses dynamically. But this will be rejected (or at least warned against) by eg SWI beginning with version 6 (I believe) introducing ISO 2012 corrigenda, since false/0 is a static procedure ie. SWI's bootstrap file contains a definition false :- fail but doesn't declare false/0 to be dynamic.
- YeGoblynQueenne 5y agoThanks, I didn't know that. I haven't worked with Aleph much and when I used it I didn't have any negative examples so I missed the problems with false/0. Yes, SWI will probably complain of an attempt to redefine a static procedure if false/0 is redefined. It's actually defined in the system module (or a module imported therein) so I guess that an error will be raised even if the negative examples are declared in a module. I wonder then, how does Aleph work around that? Or does it?
- tannhaeuser 5y agoAleph was developed for running on YAP, then ported by the original developers to SWI when false/0 and other 2012 corrigenda adaptions weren't specced-out yet, and hasn't changed since. So Aleph itself doesn't work around anything, and we can only look at a recent SWI port of Aleph instead. [1] quite radically changes the presentation of examples and background knowledge, triggering their loading off a single Prolog source file and making heavy use of directives to switch between pos/neg examples and background knowledge. I'm sure the author has somehow taken care of false/0, but a problem of that port of Aleph is that it won't work with the relative wealth of existing problem/data files in their original representation. [1]: https://github.com/friguzzi/aleph https://github.com/friguzzi/aleph
- YeGoblynQueenne 5y agoThank you for your patience! Looking at the github repository for aleph, under examples/abduce.pl I can see the source of my confusion: like you say, negative examples are now given as (FOL) atoms (Prolog "facts"). I seem to remember that in Aleph (as in Progol) examples are arbitrary definite clauses (with or without bodies) and _negative_ examples are arbitrary Horn _goals_ (from which "constraints" can be learned- i.e. Horn goals again). If that's so, then the notation "false:- <body>" is a convention to facilitate parsing of negative examples; because writing them as Horn goals (:-A,B,C...) would cause them to be parsed as directives by the Prolog interpreter- and executed...! So "false" in the head is a bit of a hack to begin with, or anyway a bit of syntactic sugar. This actually points to a slight inconsistency between theory and practice in ILP, at least when the target language is Prolog. As a reminder, this is the standard setting for ILP: given background knowledge B and positive and negative examples E⁺, E⁻, find a hypothesis H such that H ∧ B ⊨ E⁺ and ∀e⁻ ∈ E⁻: H ∧ B ⊭ e⁻. That makes a lot of sense intuitively: we want a correct hypothesis that entails all the positive and none of the negative examples, with respect to background knowledge. But it leaves open the question of what, exactly, are the negative examples. Especially when the target language is Prolog where we're operating under a closed-world assumption, where we only define the things we know to be true, it gets a bit tricky to explain how some examples (be they clauses or atoms) are "negative" when there's no real way to represent negation (only negation-as-failure) in a logic program (i.e. a set of definite clauses- no Horn goals in there!). For me the ideal answer is that positive examples are atoms in the Herbrand base of a target predicate (the "top" predicate in H) that are assigned the value "true" by an interpretation ι, where H is a "name" for ι. So, negative examples must be the same as positive examples: atoms, assigned the value "false" by ι. So they should be written as atoms, without negation. That simplifies notation, allows learning a "contra-theory" (by switching the signs of E⁺ and E⁻) and avoids the need for syntactic conventions like "false:- <body>". But, my intuition is coloured from my experience with Meta-Interpretive Learning systems where examples are always atoms and learning is a proof by SLD-refutation of examples, both positive and negative (as opposed to inverse resolution which is... more complicated; let's just say that MIL makes a lot more sense to me than IR). Digression, eh!