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
On Mon, Oct 17, 2016 at 2:40 AM, Nil Geisweiller
<ngeis...@googlemail.com <mailto: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/5808AAC1.4000004%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
