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/CAHrUA35RygO2MWjZJ2MfEA2TCvBC8kjvFDVvj2-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/msgid/opencog/57FF2210.9090304%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to