Ah, the exception was due to a bug in the original email. After fixing
that, it the code works just fine, I don't see what the problem is. Cut n
paste of the works-for-me version below.
--linas
(use-modules (opencog) (opencog query) (opencog exec))
(define g
(Get
(VariableList
(TypedVariable
(Variable "$X")
(Type "TypedVariableLink"))
(TypedVariable
(Variable "$P")
(Type "PredicateNode"))
(TypedVariable
(Variable "$Q")
(Type "PredicateNode")))
(LocalQuote
(ImplicationScope
(Variable "$X")
(Variable "$P")
(Variable "$Q")))))
;; except to find this
(ImplicationScope
(TypedVariableLink
(VariableNode "vvv")
(TypeNode "ConceptNode")
)
(PredicateNode "ppp")
(PredicateNode "qqq"))
(cog-execute! g)
;; returns the expected result. What is the problem?
On Wed, Nov 16, 2016 at 11:49 AM, Linas Vepstas <[email protected]>
wrote:
>
>
> On Wed, Nov 16, 2016 at 5:34 AM, 'Nil Geisweiller' via opencog <
> [email protected]> wrote:
>
>> I'm back to this issue.
>>
>> The notion of LocalQuote is indeed incompatible with systematic
>> alpha-conversion.
>>
>> Consider this pattern
>>
>> (Get
>> (VariableList
>> (TypedVariable
>> (Variable "$X")
>> (Type "TypedVariableLink"))
>> (TypedVariable
>> (Variable "$P")
>> (Type "PredicateNode"))
>> (TypedVariable
>> (Variable "$Q")
>> (Type "PredicateNode"))
>> (LocalQuote
>> (ImplicationScope
>> (Variable "$X")
>> (Variable "$P")
>> (Variable "$Q"))))
>>
>> This fetches ImplicationScope links.
>
>
> Well, no, it throws an error:
>
> ERROR: Throw to key `C++-EXCEPTION' with args `("cog-new-link" "Expected
> a VariableNode or a TypedVariableLink, got: LocalQuoteLink
> (/home/linas/src/novamente/src/atomspace-git/opencog/
> atoms/core/VariableList.cc:61)")'.
>
> That's with a pull from just now.
>
> anyway, it is designed to fetch ImplicationScopeLinks that are
> ill-formed. It's declared to find links like this:
>
> (ImplicationScope
> (TypedVariableLink
> (TypeNode "ConceptNode")
> (VariableNode "vvv"))
> (PredicateNode "pa")
> (PredicateNode "qa"))
>
> the variable never appears anywhere. Its -- well, the variable can be
> completely discarded, and you'd get an equivalent ImplicationScope that
> does not have any variables in it.
>
>
>> If the following
>>
>> (ImplicationScope
>> (Variable "$X")
>> (Variable "$P")
>> (Variable "$Q"))
>>
>> happen to be alpha-equivalent to something with different variable names
>> it will render the Bind link invalid.
>>
>
> ? I don't understand what you're saying. Why would it be "invalid"? Is
> there a bug? What do you mean by "happens to be alpha-equivalent"? It is,
> by definition, alpha-equivalent to an infinite number of other links.
>
>
>
>>
>> Indeed alpha-conversion shouldn't be triggered in that case,
>
>
> In which case? Alpha conversion of what?
>
>
>> the right idea is that the ImplicationScope, when quoted corresponds to a
>> DIFFERENT atom than the one not being quoted.
>
>
> Can you clarify?
>
>
>> Also of course if we decide to not perform systematic alpha-conversion
>> then this problem doesn't arise.
>>
>
> You want to eliminate ScopeLink and Lambda Link ? That's a very serious
> change.
>
>
>>
>> I'm re-iterating my question. Do we really want automatic
>> alpha-conversion to begin with?
>>
>
> What do you mean when you say "automatic"? Either there is alpha
> conversion, or there is not. What else can it be?
>
>
>>
>> If the answer is yes then I suppose we need a way to tell that the quoted
>> version is different than then unquoted version.
>>
>
> what is different from what? A better example is needed.
>
> --linas
>
>
>>
>> Nil
>>
>>
>> On 10/22/2016 03:34 AM, Ben Goertzel wrote:
>>
>>> Nil,
>>>
>>> Just brainstorming here, but perhaps the command for adding an Atom
>>> should have an option that the user can set, which determines whether
>>> the results would be alpha-converted or not
>>>
>>> The default would be to do the alpha-conversion (which would be
>>> appropriate if the variable names are say randomly generated, and thus
>>> of no particular importance to the user -- the alpha conversion is
>>> then just preventing odd collisions between randomly generated
>>> variable names created by two different processes)
>>>
>>> However, if the user wants they can override this default and specify
>>> "no alpha conversion", and then it is their responsibility to check
>>> and be sure their chosen VariableNode names are not going to be used
>>> in a way that creates some conflict ...
>>>
>>> This option would need to be added to Scheme, python, Haskell
>>> bindings, but also to the core API for adding scoped links, I guess...
>>>
>>> I am only about 83.456% sure I understand the problem here...
>>>
>>> -- Ben
>>>
>>>
>>>
>>> On Fri, Oct 21, 2016 at 11:55 PM, 'Nil Geisweiller' via opencog
>>> <[email protected]> wrote:
>>>
>>>> Hi,
>>>>
>>>> I start to think that automatic alpha-conversion is evil.
>>>>
>>>> First let me recall what it does. Say you've added
>>>>
>>>> (Scope (VariableList (Variable "$X") (Variable "$Y"))
>>>> (And (Variable "$X") (Variable "$Y")))
>>>>
>>>> and you subsequently add
>>>>
>>>> (Scope (And (Variable "$gold") (Variable "$silver")))
>>>>
>>>> then recalling the handle of that last addition, you'd get the first
>>>> alpha-equivalent scope, which is
>>>>
>>>> (Scope (VariableList (Variable "$X") (Variable "$Y"))
>>>> (And (Variable "$X") (Variable "$Y")))
>>>>
>>>> This is rather confusing to the user, but even worse the pattern matcher
>>>> behaves differently with the former or the latter. If you use the
>>>> former to
>>>> match grounds containing variables "$X" and "$Y" it may not work due to
>>>> the
>>>> pattern matcher discarding self-matches. The latter would match UNLESS
>>>> the
>>>> former has been previously added, because the variables "$gold" and
>>>> "$silver" would be silently replaced by "$X" and "$Y". This is horribly
>>>> confusing to the user!
>>>>
>>>> Second, it seems rather arbitrary to try to detect this kind of
>>>> equivalence
>>>> while there's an infinity of others. For instance
>>>>
>>>> (And (Variable "$X") (And (Variable "$Y"))
>>>>
>>>> is equivalent to
>>>>
>>>> (And (Variable "$X") (Variable "$Y"))
>>>>
>>>> For these reasons I think semantic equivalence detection shouldn't be
>>>> incorporated into the AtomSpace. The AtomSpace should take care of the
>>>> syntax only (OK, with the exception of unordered links), as it's always
>>>> been, and this task should differed to another process working above the
>>>> AtomSpace.
>>>>
>>>> It was suggested a while ago to have a normal form reduction engine for
>>>> the
>>>> AtomSpace, similar to MOSES', and such an engine could be used to reduce
>>>> while adding atoms, if the user chooses so. This is a much cleaner way
>>>> to
>>>> handle that. Also since semantic equivalence is undecidable, there will
>>>> always be a battle between completeness and performance. Another reason
>>>> to
>>>> have this ever growing monster above the AtomSpace rather than in it.
>>>>
>>>> OK, I don't know if I've convinced you, or even if I've convinced
>>>> myself,
>>>> but it's really a discussion we need to have.
>>>>
>>>> Opinions welcome.
>>>>
>>>> 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 [email protected].
>>>> To post to this group, send email to [email protected].
>>>> 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/580A3A75.1020708%40gmail.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 [email protected].
>> To post to this group, send email to [email protected].
>> Visit this group at https://groups.google.com/group/opencog.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/opencog/582C444E.4030706%40gmail.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 [email protected].
To post to this group, send email to [email protected].
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/CAHrUA36wu5Kv7PtyCPn2crbsqyu8C3rgMR49_nqLLgYSFZ4TCg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
