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