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








On Mon, Oct 17, 2016 at 2:40 AM, Nil Geisweiller <ngeis...@googlemail.com>
wrote:

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

-- 
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/CAHrUA345VEUAYFxResq6PD-RrjRC58fisxM-MaCCPa60qcdU8Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to