OK, I'll defer the conversation. Sooner or later, Amen will open another bug report once again titled "question: feature or bug?" and I guess we can deal with it then.
--linas On Thu, Oct 13, 2016 at 12:56 AM, 'Nil Geisweiller' via opencog < opencog@googlegroups.com> wrote: > On 10/13/2016 02:38 AM, Ben Goertzel wrote: > >> Wait ... we can have nested ScopeLinks, so that a variable embedded in >> two ScopeLInks can be bound by the outer one or the inner one... no? >> > > Yes, no problem, if a variable is scoped by both then the inner one will > cover the outer one. > > Anyway, I don't see a problem with having a C++ ImplicationLink class > inherit the ScopeLink class. The only think to take care of is to have no > variable extracted when there are 2 arguments, that is when using the non > sugar for of the ImplicationLink > > ImplicationLink > P > Q > > I think that is what the code does, but if it doesn't or its buggy it > should be fixed, I'm happy to fix it as soon as unit test fails because of > it. > > Nil > > > >> On Wed, Oct 12, 2016 at 4:08 PM, Linas Vepstas <linasveps...@gmail.com> >> wrote: >> >>> >>> >>> On Wed, Oct 12, 2016 at 12:53 PM, Nil Geisweiller < >>> ngeis...@googlemail.com> >>> wrote: >>> >>>> >>>> >>>> >>>> On 10/12/2016 06:55 PM, Linas Vepstas wrote: >>>> >>>>> >>>>> Well, yes, but Nil,, look at the core issue: the variable X in the >>>>> Implication link is bound, but the unit test is pretending that its >>>>> free. My question is: are you *sure* you really want the >>>>> implicationLink to inherit from Scope Link (and thus, always bind it's >>>>> variables)? >>>>> >>>> >>>> >>>> X is supposed to be free in the ImplicationLink, >>>> >>> >>> >>> Really? The C++ code has ImplicationLink inheriting from ScopeLink, thus >>> making it bound. Perhaps ImplicationLink should not inherit from >>> ScopeLink? >>> >>> ? >>> >>> >>>> bound to the PutLink. Yes I am sure I want it free in the >>>> ImplicationLink. >>>> Having ImplicationLink inherit Scope should not prevent that. The syntax >>>> itself is ambiguity free, if there are ambiguities in the code it's a >>>> bug >>>> and it should be fixed. >>>> >>>> Again, I'm happy to fix anything related to that once the issue >>>> reappears. >>>> >>>> Nil >>>> >>>> >>>>> --linas >>>>> >>>>> >>>>> On Wed, Oct 12, 2016 at 10:39 AM, Nil Geisweiller >>>>> <ngeis...@googlemail.com <mailto:ngeis...@googlemail.com>> wrote: >>>>> >>>>> OK, when they fail again I guess you might feel free to push to >>>>> the >>>>> master, as we're apparently using as a dev branch, and then I'll >>>>> fix >>>>> that. >>>>> >>>>> Nil >>>>> >>>>> On 10/12/2016 06:17 PM, Linas Vepstas wrote: >>>>> >>>>> No, actually, I worked around that. >>>>> >>>>> The only reason that PutLinkUTest currently passes is because >>>>> PutLink >>>>> fails to treat ScopeLinks correctly. When that gets fixed, >>>>> the >>>>> unit >>>>> test will fail ... the issue remains the same. >>>>> >>>>> --linas >>>>> >>>>> On Tue, Oct 11, 2016 at 11:57 PM, Nil Geisweiller >>>>> <ngeis...@googlemail.com <mailto:ngeis...@googlemail.com> >>>>> <mailto:ngeis...@googlemail.com >>>>> <mailto:ngeis...@googlemail.com>>> wrote: >>>>> >>>>> Are these unit tests still failing? >>>>> >>>>> Nil >>>>> >>>>> >>>>> On 10/11/2016 08:36 PM, Linas Vepstas wrote: >>>>> >>>>> 47 unit tests fail ... I'm not sure if they all fail >>>>> for the same >>>>> reason, though. >>>>> >>>>> For example PutLink >>>>> >>>>> (PutLink >>>>> (LambdaLink >>>>> (VariableList >>>>> (TypedVariableLink >>>>> (VariableNode "$X") >>>>> (TypeNode "PredicateNode") >>>>> ) >>>>> (TypedVariableLink >>>>> (VariableNode "$Y") >>>>> (TypeNode "PredicateNode") >>>>> ) >>>>> ) >>>>> (AndLink >>>>> (EvaluationLink >>>>> (PredicateNode "acquainted") >>>>> (ListLink >>>>> (VariableNode "$X") >>>>> (VariableNode "$Y") >>>>> ) >>>>> ) >>>>> (ImplicationLink >>>>> (VariableNode "$X") ; this is >>>>> alpha-converted to $foo1233 >>>>> (PredicateNode "is-human") >>>>> ) >>>>> (ImplicationLink >>>>> (VariableNode "$X") ; this is >>>>> alpha-converted to $bar456 >>>>> (PredicateNode "is-human") >>>>> ) >>>>> ) >>>>> ) >>>>> (ListLink >>>>> (PredicateNode "is-Self") >>>>> (PredicateNode "is-Bob") >>>>> ) >>>>> ) >>>>> >>>>> So, because the implication link is scoped, the >>>>> result >>>>> of the >>>>> variable >>>>> substitution is >>>>> >>>>> (AndLink >>>>> (ImplicationLink >>>>> (VariableNode "$foo123") >>>>> (PredicateNode "is-human") >>>>> ) >>>>> (ImplicationLink >>>>> (VariableNode "$bar456") >>>>> (PredicateNode "is-human") >>>>> ) >>>>> (EvaluationLink >>>>> (PredicateNode "acquainted") >>>>> (ListLink >>>>> (PredicateNode "is-Self") >>>>> (PredicateNode "is-Bob") >>>>> ) >>>>> ) >>>>> ) >>>>> >>>>> which is not what the unit test expects. The problem >>>>> with using >>>>> either >>>>> ScopeLink or LambdaLink is that it becomes impossible >>>>> to have a >>>>> stable >>>>> variable name -- it can be alpha-converted to >>>>> anything, >>>>> so any >>>>> algo that >>>>> depends on having a fixed, well-known variable name >>>>> will fail. >>>>> >>>>> In this case -- I am not sure -- if you want >>>>> ImplicationLink to be >>>>> scoped, then the unit test is wrong. But is the unit >>>>> test is right, >>>>> then implication link must not be scoped. I cannot >>>>> tell which >>>>> one is >>>>> wanted. >>>>> >>>>> --linas >>>>> >>>>> >>>>> >>>>> On Tue, Oct 11, 2016 at 12:12 PM, Nil Geisweiller >>>>> <ngeis...@googlemail.com >>>>> <mailto:ngeis...@googlemail.com> <mailto: >>>>> ngeis...@googlemail.com >>>>> <mailto:ngeis...@googlemail.com>> >>>>> <mailto:ngeis...@googlemail.com >>>>> <mailto:ngeis...@googlemail.com> >>>>> >>>>> <mailto:ngeis...@googlemail.com >>>>> <mailto:ngeis...@googlemail.com>>>> wrote: >>>>> >>>>> Linas, >>>>> >>>>> I don't have time to get into that right now. If >>>>> you can >>>>> point to >>>>> where exactly it breaks (like a unit test on >>>>> your >>>>> branch) >>>>> it would >>>>> help. In any case I look carefully into that and >>>>> reply >>>>> tomorrow. >>>>> >>>>> Nil >>>>> >>>>> >>>>> On 10/11/2016 06:55 PM, Linas Vepstas wrote: >>>>> >>>>> You made it inherit from ScopeLink, thus >>>>> making the >>>>> variables in it >>>>> implicitly scoped. Then you added the file >>>>> ImplicationLink.cc, >>>>> and have >>>>> notes in there, complaining about how >>>>> variables are >>>>> implcitly >>>>> scoped. >>>>> The wiki page for it, >>>>> http://wiki.opencog.org/w/ImplicationLink >>>>> <http://wiki.opencog.org/w/ImplicationLink> >>>>> <http://wiki.opencog.org/w/ImplicationLink >>>>> <http://wiki.opencog.org/w/ImplicationLink>> >>>>> <http://wiki.opencog.org/w/ImplicationLink >>>>> <http://wiki.opencog.org/w/ImplicationLink> >>>>> <http://wiki.opencog.org/w/ImplicationLink >>>>> <http://wiki.opencog.org/w/ImplicationLink>>> still >>>>> says things that are wrong (re alpha >>>>> conversion -- each >>>>> lambda gets >>>>> alpha converted, so the "sugar syntax" >>>>> section >>>>> cannot >>>>> possibly >>>>> be right). >>>>> >>>>> I'm asking, because I'm trying to fix #910 >>>>> by >>>>> doing the >>>>> alpha >>>>> conversion >>>>> correctly, and the result of the fix is that >>>>> unit tests >>>>> with >>>>> implication >>>>> links in them now fail. The whole thing >>>>> smells bad. >>>>> >>>>> Either ImplicationLinks do inherit from >>>>> ScopeLink, in which >>>>> case, there >>>>> should be no complaints about how the >>>>> ScopeLink works: >>>>> it does >>>>> the right >>>>> thing. If you don't like what the scopeLink >>>>> does, then >>>>> ImplicationLinks >>>>> should NOT inherit from it ... >>>>> >>>>> In either case, the wiki page needs fixing, >>>>> because the >>>>> alpha >>>>> conversion >>>>> conversation we had recently renders that >>>>> page >>>>> incoherent. >>>>> >>>>> I don't really care, one way or the other, >>>>> but >>>>> I do need to >>>>> understand >>>>> the intended design well enough to be able >>>>> to >>>>> fix bugs, and >>>>> right now, I >>>>> don't understand what ImplicationLink is, or >>>>> how its >>>>> supposed to >>>>> work. >>>>> >>>>> --linas >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "opencog" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to opencog+unsubscr...@googlegroups.com. >>> To post to this group, send email to opencog@googlegroups.com. >>> Visit this group at https://groups.google.com/group/opencog. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/opencog/CAHrUA35RygO2MWjZJ >>> 2MfEA2TCvBC8kjvFDVvj2-CNmqP2e9PLQ%40mail.gmail.com. >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> > -- > You received this message because you are subscribed to the Google Groups > "opencog" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to opencog+unsubscr...@googlegroups.com. > To post to this group, send email to opencog@googlegroups.com. > Visit this group at https://groups.google.com/group/opencog. > To view this discussion on the web visit https://groups.google.com/d/ms > gid/opencog/57FF2210.9090304%40gmail.com. > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "opencog" group. To unsubscribe from this group and stop receiving emails from it, send an email to opencog+unsubscr...@googlegroups.com. To post to this group, send email to opencog@googlegroups.com. Visit this group at https://groups.google.com/group/opencog. To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA34iyZq3CBTSPh80GLdBMH2SFBHKpr4NyzqQ5_PGXXSQ5g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
