Higher order goals?

[EllenOrange]

Suppose I have objects of type room, which in turn can be connected to other rooms via a door predicate. To keep queries from going into infinite loops, we view these doors as directional, and then write a rule that determines if these rooms are connected. You may recognize this situation from Amzi! prolog's nanisrch example. :)

In vanilla prolog, this is very straight forward.

room(kitchen).
room(cellar).
door(kitchen, cellar).

connect(X, Y) :-
	door(X, Y).
connect(X, Y) :-
	door(Y, X).

Rendering these ideas into logtalk, I get something like

:- object(room).
	:- public(door_to/1).
	:- mode(door_to(?room),zero_or_more).

	:- public(connected_to/1).
	connected_to(To) :-
		::door_to(To).
	connected_to(To) :-
		self(From),
		To::door_to(From).
:- end_object.

:- object(cellar, extends(room) ).
:- end_object.

:- object(kitchen, extends(room) ).
	door_to(cellar).
:- end_object.

yielding

[debug] 5 ?- kitchen::door_to(cellar).
true.

[debug] 6 ?- kitchen::connected_to(cellar).
true .

[debug] 7 ?- cellar::connected_to(kitchen).
true.

[debug] 8 ?- cellar::connected_to(X).
!     Instantiation error
!       in goal: A::door_to(cellar)
!       with execution context:
!         entity:            room
!         sender:            user
!         this:              room
!         self:              cellar
!         meta-call context: []
!         coinduction stack: []

In prolog this doesn't require any sort of higher order goal, but in logtalk I don't see a straight forward way of querying X::door_to(Y).

I've probably missed something, so I thought I'd check in with the maestro.

[pmoura]

Can you keep rooms and doors as Prolog facts? Or do you have more to say about rooms and doors?

[EllenOrange]

Yes, I could do that. I could represent kitchen::door_to(cellar) as kitchen::door_to(kitchen, cellar), for example.

Of course this is a test case for the actual system I'm prototyping, and doing it that way would imply that all binary relations in my system would be represented in the form domain::relation(domain,range). That seems like a misuse of Logtalk, in that I'd mainly be using it as an improved module system.

[pmoura]

P.S. I was thinking about a solution using parametric objects and parametric objects proxies. See the proxies example.

But going back to your code, the usual solution is to define a marker protocol that your rooms will implement and then call implements_protocol(Room, room_protocol) in your connected_to/1 predicate to enumerate rooms and thus avoid that instantiation error.

[EllenOrange]

Okay, got it.

X::relation(Y) works as long as I generate the possibilities for X myself. In the usual solution, you do that using the room_protocol, which lets me find all the objects that implement that prototcol and implicitly are rooms.

If I were using an class/instance hierarchy for this (as we've discussed elsewhere), I imagine I could achieve the same thing via instantiates_class( X, room).

Thanks again for the help!