Code Inheritance question

[Eleanor Todd]

Hi folks,

I have a few questions about Code Inheritance, as defined in section 22.5 of the Ergo manual.

• When I run the example as described, it works fine, but gives the warning "HiLog function symbol was also used with a different number of arguments on line XX in the same file. If this is not an error, use the symbol_context directive to suppress this warning". I've tried using the symbol_context directive as instructed, but I can't manage to figure out the correct syntax for referring to something of the form ?X[foo(?Y) -> ?Z]
• Is there a way of referring to foo and bar when assigning them that avoids the error entirely? I tried doing c1[|dispatch(meth) -> bar($_)|]. but that gives runtime errors.
• Why is dispatch(?) needed in this example? If I rewrite the last 3 lines without it, the correct answers are still returned, with no more warnings than I've already mentioned. :)

Any thoughts or advice?

For ease of reference reference, the original code in the manual is:

aa:c1.
bb:c2.
c1::c2.
aa[attr1->7, attr2->2].
bb[attr1->5, attr2->4].

// Step 1: define auxiliary methods.
// auxiliary method foo/1 defined for every instance
?X[foo(?Y) -> ?Z] :- ?X[attr1->?V], ?Z \is ?V+?Y.
// auxiliary method bar/1 defined for every instance
?X[bar(?Y) -> ?Z] :- ?X[attr2->?V], ?Z \is ?V*?Y.

// Step 2: define the “fake” method meth.
c1[|dispatch(meth) -> bar|].
c2[|dispatch(meth) -> foo|].

// Step 3: finishing up.
?X[?M(?Y) -> ?Z] :- ?X[dispatch(?M)->?RealMeth], ?X[?RealMeth(?Y) -> ?Z].

[Michael Kifer]

On 4/6/23 10:04 AM, Eleanor Todd wrote:
> Hi folks,
>
> I have a few questions about Code Inheritance, as defined in section
> 22.5 of the Ergo manual.
>

> * When I run the example as described, it works fine, but gives the

> warning "HiLog function symbol was also used with a different
> number of arguments on line XX in the same file. If this is not an
> error, use the symbol_context directive to suppress this warning".
> I've tried using the symbol_context directive as instructed, but I
> can't manage to figure out the correct syntax for referring to
> something of the form ?X[foo(?Y) -> ?Z]
>

The simple way to get rid of these warnings is to add

:- symbol_context{bar/0, foo/0}.

at the top. Or even

:- symbol_context{bar/?, foo/?}.

if these symbols are additionally used with 2,3,etc. args.


Note: symbol_context controls the warnings about the occurrences of the
same symbol as a function term with different number of args or the same
symbol as a function and as a predicate.


> * Is there a way of referring to foo and bar when assigning them

> that avoids the error entirely? I tried doing c1[|dispatch(meth)
> -> bar($_)|]. but that gives runtime errors.
>

Not sure what you mean here, especially the $_ part.

Maybe

:- symbol_context{bar/?, foo/?}.

is what you want?


> * Why is dispatch(?) needed in this example? If I rewrite the last 3

> lines without it, the correct answers are still returned, with no
> more warnings than I've already mentioned. :)
>

One can get the correct answer in many different ways. The point here is
to illustrate how code inheritance, which is *not* supported in Ergo
directly, can be *simulated* via property inheritance, which *is*
supported in Ergo directly. The use of dispatch/1 is just one element in
that simuation


Code inheritance is typically used in programming languages like Java,
C++. Property inheritance is more common in KR.

The above simulation is not particularly elegant, but is not too bad
either.

--

       --- michael

> Any thoughts or advice?
>
> For ease of reference reference, the original code in the manual is:
>
> aa:c1.
> bb:c2.
> c1::c2.
> aa[attr1->7, attr2->2].
> bb[attr1->5, attr2->4].
>
> // Step 1: define auxiliary methods.
> // auxiliary method foo/1 defined for every instance
> ?X[foo(?Y) -> ?Z] :- ?X[attr1->?V], ?Z \is ?V+?Y.
> // auxiliary method bar/1 defined for every instance
> ?X[bar(?Y) -> ?Z] :- ?X[attr2->?V], ?Z \is ?V*?Y.
>
> // Step 2: define the “fake” method meth.
> c1[|dispatch(meth) -> bar|].
> c2[|dispatch(meth) -> foo|].
>
> // Step 3: finishing up.
> ?X[?M(?Y) -> ?Z] :- ?X[dispatch(?M)->?RealMeth], ?X[?RealMeth(?Y) -> ?Z].

> --
> You received this message because you are subscribed to the Google
> Groups "ErgoAI and XSB Users Forum" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to ErgoAI-XSB-for...@coherentknowledge.com
> <mailto:ErgoAI-XSB-for...@coherentknowledge.com>.
> To view this discussion on the web visit
> https://groups.google.com/a/coherentknowledge.com/d/msgid/ErgoAI-XSB-forum/3855fd4a-3028-4cf4-93ff-1ad74e517256n%40coherentknowledge.com
> <https://groups.google.com/a/coherentknowledge.com/d/msgid/ErgoAI-XSB-forum/3855fd4a-3028-4cf4-93ff-1ad74e517256n%40coherentknowledge.com?utm_medium=email&utm_source=footer>.

[Eleanor Todd]

Thanks so much for your help!

> * Is there a way of referring to foo and bar when assigning them
> that avoids the error entirely? I tried doing c1[|dispatch(meth)
> -> bar($_)|]. but that gives runtime errors.

Not sure what you mean here, especially the $_ part.

Maybe :- symbol_context{bar/?, foo/?}. is what you want?

 

I'm asking if there is a way to avoid generating the warning, rather than silencing it using :- symbol_context.

The point here is to illustrate how code inheritance, which is *not* supported in Ergo
directly, can be *simulated* via property inheritance, which *is*
supported in Ergo directly. The use of dispatch/1 is just one element in

that simulation. The above simulation is not particularly elegant, but is not too bad
either.

Got it, thanks. It seems like it should work for my purposes. :)

[Michael Kifer]

On 4/6/23 4:05 PM, Eleanor Todd wrote:

Thanks so much for your help!

> * Is there a way of referring to foo and bar when assigning them
> that avoids the error entirely? I tried doing c1[|dispatch(meth)
> -> bar($_)|]. but that gives runtime errors.

Not sure what you mean here, especially the $_ part.

Maybe :- symbol_context{bar/?, foo/?}. is what you want?

 

I'm asking if there is a way to avoid generating the warning, rather than silencing it using :- symbol_context.

it's the warnoff option in symbol_context.

But this is a really bad idea unless you are absolutely certain that everything is correct.

--

       --- michael