ImplicationLink?

[Linas Vepstas]

Nil,

Can you explain the intent of ImplicationLink?  

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 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

[Nil Geisweiller]

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

[Linas Vepstas]

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

[Nil Geisweiller]

Are these unit tests still failing?

Nil

[Linas Vepstas]

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 

[Nil Geisweiller]

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

> <mailto:ngei...@googlemail.com

[Linas Vepstas]

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

[Ben Goertzel]

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...

> --
> 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+u...@googlegroups.com.
> To post to this group, send email to ope...@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...

[Linas Vepstas]

Ben, that's fine, I don't care.  But if that is what you want, then the unit test is wrong.  I'm just asking for confirmation, before I change it, since Nil wrote the unit test.

--linas

>>>         <ngei...@googlemail.com <mailto:ngeiswei@googlemail.com>
>>>         <mailto:ngeiswei@googlemail.com

> email to opencog+unsubscribe@googlegroups.com.

> To post to this group, send email to ope...@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+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@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.

[Nil Geisweiller]

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, 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
> <ngei...@googlemail.com <mailto:ngei...@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
> <ngei...@googlemail.com <mailto:ngei...@googlemail.com>

[Linas Vepstas]

On Wed, Oct 12, 2016 at 12:53 PM, Nil Geisweiller <ngei...@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?

?

 

                 <mailto:ngeiswei@googlemail.com
        <mailto:ngei...@googlemail.com>

                 <mailto:ngeiswei@googlemail.com

[Ben Goertzel]

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?

>>> <mailto:ngei...@googlemail.com

> --
> 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+u...@googlegroups.com.

> To post to this group, send email to ope...@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.

[Nil Geisweiller]

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

[Linas Vepstas]

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

         <mailto:ngeiswei@googlemail.com

         <mailto:ngeiswei@googlemail.com> <mailto:ngei...@googlemail.com
         <mailto:ngeiswei@googlemail.com>>
                  <mailto:ngei...@googlemail.com
         <mailto:ngeiswei@googlemail.com>

                  <mailto:ngei...@googlemail.com

email to opencog+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@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+unsubscribe@googlegroups.com.

To post to this group, send email to ope...@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.

[Linas Vepstas]

Shortly after sending this message, I decided that it was a bad idea to let a sleeping bug lie. I am totally and completly confused by ImplicationLink.   I flat out do not understand it, at all, not one whit.

Consider this:

(ImplicationLink  (VariableNode "$X")   (PredicateNode "is-human"))

In C++ I can cast this to a ScopeLink, and then as the ScopeLink "what are your variables?"  and I get back the answer "None".

That's it, game over. My brain no longer functions.   What does it mean, to have a link that has variables, to not have variables in it???  

My knee-jerk reaction is that the code is buggy, that it is a mistake to have ImplicationLink inherit from ScopeLink, that some chain of accidents lead to this point.   The wikipage is utterly incomprehensible: I don't understand it either.  What is Implication?  Can we fix this so it makes sense in some way?

--linas

[Nil Geisweiller]

On 10/16/2016 07:32 AM, Linas Vepstas wrote:
> Shortly after sending this message, I decided that it was a bad idea to
> let a sleeping bug lie. I am totally and completly confused by
> ImplicationLink. I flat out do not understand it, at all, not one whit.
>
> Consider this:
>
> (ImplicationLink (VariableNode "$X") (PredicateNode "is-human"))
>
> In C++ I can cast this to a ScopeLink, and then as the ScopeLink "what
> are your variables?" and I get back the answer "None".

The answer is correct, $X is not scoped under the ImplicationLink. The
ONLY way to have variables scoped under an ImplicationLink is to use the
form

Implication
<variable declaration>
<implicant>
<implicand>

Here specifically $X has got to be something akin to a PredicateNode, a
Lambda or anything that acts is like a predicate, i.e. a function with
co-domain TV.

>
> That's it, game over. My brain no longer functions. What does it mean,
> to have a link that has variables, to not have variables in it???

The variable may still be scoped but not in the ImplicationLink.

>
> My knee-jerk reaction is that the code is buggy, that it is a mistake to
> have ImplicationLink inherit from ScopeLink, that some chain of

The code is/should-be not buggy.

> accidents lead to this point. The wikipage is utterly
> incomprehensible: I don't understand it either. What is Implication?
> Can we fix this so it makes sense in some way?

Oh, perhaps the confusion comes from this: unlike most scope links, when
an ImplicationLink has no variable declaration it is not assumed that
all free variables are under its scope.

I've added a note about it in the wiki.

Maybe we should split this in two link types.

ImplicationLink

ImplicationScopeLink

The ImplicationLink would be used only with the form

ImplicationLink
<implicant>
<implicand>

and ImplicationScopeLink only with these forms

ImplicationScopeLink
<variable declaration>
<implicant-body>
<implicand-body>

ImplicationScopeLink
<implicant-body>
<implicand-body>

Only ImplicationScopeLink would inherit ScopeLink and would implicitly
scopes the free variables when the variable declaration is missing, like
the other scope links.

What do you think?

Nil

> <ngei...@googlemail.com <mailto:ngei...@googlemail.com>>

> <mailto:ngei...@googlemail.com

> <mailto:ngei...@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
> <ngei...@googlemail.com
> <mailto:ngei...@googlemail.com>

> <mailto:ngei...@googlemail.com

> <mailto:ngei...@googlemail.com>>
> <mailto:ngei...@googlemail.com
> <mailto:ngei...@googlemail.com>
> <mailto:ngei...@googlemail.com

> <mailto:ngei...@googlemail.com>

> <mailto:ngei...@googlemail.com
> <mailto:ngei...@googlemail.com>>
> <mailto:ngei...@googlemail.com
> <mailto:ngei...@googlemail.com>
> <mailto:ngei...@googlemail.com
> <mailto:ngei...@googlemail.com>>>
>
> <mailto:ngei...@googlemail.com
> <mailto:ngei...@googlemail.com>
> <mailto:ngei...@googlemail.com
> <mailto:ngei...@googlemail.com>>
>
>
> <mailto:ngei...@googlemail.com
> <mailto:ngei...@googlemail.com>
> <mailto:ngei...@googlemail.com

> email to opencog+u...@googlegroups.com
> <mailto:opencog%2Bunsu...@googlegroups.com>.

> To post to this group, send email to

> ope...@googlegroups.com <mailto:ope...@googlegroups.com>.

> Visit this group at
> https://groups.google.com/group/opencog

> <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

> <https://groups.google.com/d/msgid/opencog/CAHrUA35RygO2MWjZJ2MfEA2TCvBC8kjvFDVvj2-CNmqP2e9PLQ%40mail.gmail.com>.

>
> For more options, visit
> https://groups.google.com/d/optout

> <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+u...@googlegroups.com
> <mailto:opencog%2Bunsu...@googlegroups.com>.

> To post to this group, send email to ope...@googlegroups.com

> <mailto:ope...@googlegroups.com>.

> Visit this group at https://groups.google.com/group/opencog

> <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
> <https://groups.google.com/d/msgid/opencog/57FF2210.9090304%40gmail.com>.

>
> For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.
>
>
>

[Ben Goertzel]

As for the name

> ImplicationScopeLink

at first I thought I would prefer

ScopingImplicationLink

but now I'm not sure ;p

Anyway, ugly as it is, I think it may be better to use two different
link types for the different variants, under the general principle we've been
leaning towards lately, that more explicit articulation of logical structures
in Atomspace reduces confusion, and is thus worthwhile even when it
makes things a bit less elegant...

[Nil Geisweiller]

On 10/17/2016 10:17 AM, Ben Goertzel wrote:
> As for the name
>
>> ImplicationScopeLink
>
> at first I thought I would prefer
>
> ScopingImplicationLink
>
> but now I'm not sure ;p
>
> Anyway, ugly as it is, I think it may be better to use two different
> link types for the different variants, under the general principle we've been
> leaning towards lately, that more explicit articulation of logical structures
> in Atomspace reduces confusion, and is thus worthwhile even when it
> makes things a bit less elegant...

OK. It also tends to simplify the code.

I'll wait for Linas' input (and name suggestion if he has one) and
operate the splitting.

Nil

>
>
>

[Linas Vepstas]

Ah .. OK, I'm starting to grasp it now. I almost wrote Eureka! but decided that was too strong.

Yes, it sounds like the intent is to have two link types, one that is scoped, and one that is not.  Yes, it is less confusing to have two different types, rather than having one type that tries to be both.  But all design is a tradeoff -- what do you loose, if you create two different types, here? 

Then comes a question about naming:  one possibility is:

FreeImplication inherits from FreeLink

Implication inherits from ScopeLink

But if the most common usage of Implication is free, then perhaps its a bad idea to change that name.  So the alternative is:

Implication inherits from FreeLink

XXXImplication  inherits from ScopeLink

what is XXX?

I don't like the name ScopeImplication or ImplicationScope. Not sure why.

I like BoundImplication or ImplicationBind better.   But not much. Not sure why. 

Maybe LexicalImplication ?  I like that  better than the last two -- its from reading  https://en.wikipedia.org/wiki/Scope_(computer_science)  and the understanding that opencog ScopeLink could be called the "LexicalScopeLink".  

Maybe BlockImplication because the variables are block-scoped?

The point here is that the opencog FreeLink, and the free variables it defines/finds can be thought of as sometimes being "dynamically scoped"

So -- the PLN examples that started this whole discussion treats the variables as if they were dynamically scoped! And not truly free!  So when we say "free variable" we often seem to mean "dynamically scoped variable".   -- and I believe that maybe most PLN rules use dynamically-scoped variables.

This suggests that perhaps FreeLink should be renamed to DynScopeLink and ScopeLink should be renamed to LexScopeLink ...

Not sure if that would solve problems, but I'm starting to understand the differences better, now.

By analogy, then, we should have DynImplication and LexImplication ... 

so final proposal: have:

Implication inherits from FreeLink

LexImplication  inherits from ScopeLink

-- linas

[Nil Geisweiller]

On 10/18/2016 09:14 AM, Linas Vepstas wrote:
> Ah .. OK, I'm starting to grasp it now. I almost wrote Eureka! but
> decided that was too strong.
>
> Yes, it sounds like the intent is to have two link types, one that is
> scoped, and one that is not. Yes, it is less confusing to have two
> different types, rather than having one type that tries to be both. But
> all design is a tradeoff -- what do you loose, if you create two
> different types, here?

By introducing this new link we loose

1. Time renaming half of the existing ImplicationLink in the code base

2. One less link name in the space of available link names

3. It's gonna be slightly more verbose for the user

I don't thing these reasons out weight the ambiguity cut, for both the
user and the developer it's a win, no doubt.

>
> Then comes a question about naming: one possibility is:
>
> FreeImplication inherits from FreeLink
> Implication inherits from ScopeLink

I don't think implication link should inherit from FreeLink, I mean no
more than any other link, like say AndLink needs to.

>
> But if the most common usage of Implication is free, then perhaps its a
> bad idea to change that name. So the alternative is:
>
> Implication inherits from FreeLink
> XXXImplication inherits from ScopeLink

I don't know at that point what is gonna be the most common usage, I
suspect it might be the scoped version but I'm not sure.

>
> what is XXX?
>
> I don't like the name ScopeImplication or ImplicationScope. Not sure why.
>
> I like BoundImplication or ImplicationBind better. But not much. Not
> sure why.
>
> Maybe LexicalImplication ? I like that better than the last two -- its
> from reading https://en.wikipedia.org/wiki/Scope_(computer_science) and
> the understanding that opencog ScopeLink could be called the
> "LexicalScopeLink".
>
> Maybe BlockImplication because the variables are block-scoped?
>
> The point here is that the opencog FreeLink, and the free variables it
> defines/finds can be thought of as sometimes being "dynamically scoped"

I don't see why. A FreeLink's scope is also determined statically,
right? Therefore I'm not sure this is the right dichotomy. Both are
lexical scopes, but one is implicit and the other is explicit.

>
> So -- the PLN examples that started this whole discussion treats the
> variables as if they were dynamically scoped! And not truly free! So

Hmm, again I don't in which sense they are dynamically scoped, instead
they are scoped by direct or indirect incoming links, like say for instance

ForAll
X
Implication
X
X

X is scoped in the ForAll, not the ImplicationLink, but it is scoped,
explicitly and statically.

> when we say "free variable" we often seem to mean "dynamically scoped
> variable". -- and I believe that maybe most PLN rules use
> dynamically-scoped variables.

I'm not sure.

>
> This suggests that perhaps FreeLink should be renamed to DynScopeLink
> and ScopeLink should be renamed to LexScopeLink ...
>
> Not sure if that would solve problems, but I'm starting to understand
> the differences better, now.
>
> By analogy, then, we should have DynImplication and LexImplication ...
> so final proposal: have:
>
> Implication inherits from FreeLink
> LexImplication inherits from ScopeLink

I like LexImplication cause it's short but again I'm not sure the
dichotomy lex vs dyn applies in our case. It's also slightly confusing
for someone who hasn't read the wikipage.

I don't see why

ScopingImplication or ImplicationScope isn't great.

BTW, that problem just started to manifest itself with the Backward
Chainer (cause the BIT generates ImplicationLink constructs I never had
before). I tried to fix the ImplicationLink variable extraction but got
more problems (cause implicit scoped implication is used in the opencog
repo). So I'm more than ever motivated to operate that splitting. I
guess I'll choose a name. If the name really sucks changing it shouldn't
be hard (search and replace), the hard part is gonna be the splitting.

Nil

[linas]

OK, I just got to the bottom of this email chain, and it looks OK to me.

BTW, you may want to keep this in mind: the FreeLink is just a device to "memoize" the locations of variables in an expression.  Thus, if you have an algorithm that needs to repeatedly search for variables in some link type, then it can be useful to inherit from FreeLink, -- this helps avoid the repeated search.  The FreeLink has no additional semantics: it doesn't change the meaning of anything.  

--linas

[Linas Vepstas]

Hmm. On further thought, I'm still confused. I just posted to https://github.com/opencog/atomspace/issues/977 but I will repost here, because it seems important:

Aren't the following two equivalent?

ImplicationScopeLink

     VariableNode  x

     P(x)

     Q(x)

and

ForAllLink

    VariableNode x

    ImplicationLink

        P(x)

        Q(x)

If these two are NOT equivalent, then how are they different? If they are equivalent, do we really need to have an ImplicationScopeLink?

--linas

[Ben Goertzel]

If we have

> ImplicationScopeLink
> VariableNode x
> P(x)
> Q(x)

then e.g. PLN can assign this a truth value equal to

Sum_x ( max( P(x), Q(x)) ) / Sum_x P(x)

or

Sum_x ( P(x) * Q(x) ) / Sum_x P(x)

but may assign a quite different truth value for

ForAllLink
VariableNode x
ImplicationLink
P(x)
Q(x)

PLN does assign these two constructs different uncertain truth values,
so this is not just a theoretical difference...

Other uncertain logic frameworks may also assign the two constructs
different TVs, I would think...

ben

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

“I tell my students, when you go to these meetings, see what direction
everyone is headed, so you can go in the opposite direction. Don’t
polish the brass on the bandwagon.” – V. S. Ramachandran

[Linas Vepstas]

OK, that makes sense.  In that case, though, why not invent a new SpecialAllLink which has the desired properties?  Inventing one new link for this would be more economical, and less confusing than having six new links:

ImplicationScope

IntentionalImplicationScope

ExtensionalImplicationScope

EquivalenceScope

IntensionalEquivalenceScope

ExtensionalEquivalenceScope

which is what the current code does.

Besides, come the day you want to change the PLN formula, or create yet another one, you would just need a NewFormulaLink  instead of six new links.

--linas

[Ben Goertzel]

[Ben Goertzel]

I think this may be what the

AverageQuantifierLink

used to do?

Then we could say

AverageQuantifierLink

VariableNode x
ImplicationLink
P(x)
Q(x)

and this would do what PLN needs... and if Bob had a different kind of
logic with its own formulas he could have

BobsQuantifierLink

VariableNode x
ImplicationLink
P(x)
Q(x)

But I'm not sure this would satisfy all Nil's current requirements?

ben

On Mon, Nov 7, 2016 at 11:28 PM, Linas Vepstas <linasv...@gmail.com> wrote:

[Nil Geisweiller]

I've added some notes about that

http://wiki.opencog.org/w/ExtensionalImplicationScopeLink#Remarks

My feeling based is that the ImplicationScopeLink (I mean, either mixed,
extensional or intensional) is what we want in most cases, which is good
given that it's syntactically simpler than wrapping an AverageLink or
ForAllLink around an implication.

Nil

[Linas Vepstas]

Well, this then raises another issue: we have all of these different link types -- and there are so many of them, and so many of them are almost the same but are slightly different in ways that almost no one understands.  

It seems to me that we have mixed together two different concepts: (a) the syntactic structure of links, and (b) the PLN semantics of links.  Maybe we should un-mix them.

So, to me, it seems like BindLink and ImplicationScopeLink are the same thing (at least as far as (a)-syntax is concerned), but Ben says no, they have different meanings in PLN -- one has one kind of truth value, the other has a different kind. 

Perhaps we need atoms with two different kinds of  types -- a syntactic type, which indicates what their structure is, and a semantic type, which indicates what kind of TV formulas should be used?

There are additional issues: for example: the page http://wiki.opencog.org/w/ExtensionalImplicationScopeLink#Remarks makes remarks like this:

ExtensionalImplicationScopeLink <TV>

   <vardecl>

   <implicant-body>

   <implicand-body>

is equivalent to

ExtensionalImplicationLink <TV>

   LambdaLink

      <vardecl>

      <implicant-body>

   LambdaLink

      <vardecl>

      <implicand-body>

Huh ? My head spins, I have no clue how to read or understand that.  They seem to be two completely different kinds -- the second one is a pair of combinators, the first one is not a combinator at all -- they're not even of the same kind, so how can one convert one into the other?

and then there's this:

ExtensionalImplicationScopeLink <TV>

   X

   EvaluationLink

      P

      X

   EvaluationLink

      Q

      X

is equivalent to

ExtensionalImplicationLink <TV>

   P

   Q

which cannot possibly be right -- They're not even of the same kind -- how can they possibly be convertible into one-another? 

The only part of that that does make sense to me is this:

ExtensionalImplicationScopeLink <TV>

is not equivalent to

AverageLink <TV>

Ahh!! Yes, OK, that makes sense. But this is exactly where it would be good to decouple syntax from PLN semantics.  

To recap: we seem to be using atom types to sometimes indicate (a) syntax and sometimes (b) PLN TV value formulas.   I'm thinking that maybe there is a better way to indicate which is which.

--linas

[Nil Geisweiller]

On 11/09/2016 04:33 AM, Linas Vepstas wrote:
> So, to me, it seems like BindLink and ImplicationScopeLink are the same
> thing (at least as far as (a)-syntax is concerned), but Ben says no,
> they have different meanings in PLN -- one has one kind of truth value,
> the other has a different kind.
>
> Perhaps we need atoms with two different kinds of types -- a syntactic
> type, which indicates what their structure is, and a semantic type,
> which indicates what kind of TV formulas should be used?

We could. Another way it to have different rule-bases. I've tried in the
wiki to specify when equivalences are PLN semantics specific.

The scope forms are merely sugar, the PLN formulae are derived based on
the non scope forms/combinators/higher-level-functions.

I've updated the wiki to hopefully make it clearer.

Nil