Potentially Atomspace could host other sorts of variables....  But,
since ImplicationLink is a PLN (or other formal logic) thing, it makes
sense to have the variables involved with implicationLink bound
somewhere, since that is how formal logic works, right?

Potentially this quantification could be left implicit sometimes.  But
I recall we decided a year or so ago that "implicit quantification"
was causing too much confusion, and we wanted all VariableNodes to be
bound somewhere or other in the Atomspace ....

So I think the above is the backdrop for making ImplicationLink a kind
of ScopeLink...

There may be some technical detail I am overlooking though...

On Wed, Oct 12, 2016 at 8:55 AM, Linas Vepstas <linasveps...@gmail.com> 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)?
>
> --linas
>
>
> On Wed, Oct 12, 2016 at 10:39 AM, Nil Geisweiller <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>> 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>>> 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>> 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/CAHrUA35w5rCVqPgSYr8EcmJHGRKT-g8P5%2BtoFfh2Fg2Hu06FnA%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.



-- 
Ben Goertzel, PhD
http://goertzel.org

Super-benevolent super-intelligence is the thought the Global Brain is
currently struggling to form...

-- 
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/CACYTDBd9QTQn2qdtrGh42-NnYHQQ2VvyP%3Dcurryfb_tMLsEUhg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to