Re: Prolog type overloading
- From: Jussi Piitulainen <jpiitula@xxxxxxxxxxxxxxxx>
- Date: 28 Jun 2006 15:49:38 +0300
Lekeas GK writes:
Jussi Piitulainen wrote:....
George writes:
I would like to define a predicate with the same name (next) but
with the following logic: if next succeeds with a list, check
whether the player I pass as an argument is member of that list. I
wrote it as:
next(P):-
next([S]),
member(P,[S]).
However, this results in infinite looping. Is there a better of
doing it or telling Prolog not to invoke next without a list as
the parameter?
The better way is to use different names for different
predicates.
I know - it is just that I am extending a single-user game programme
to accomodate multiple users and I thought it would be nice if I
could use the same name for predicates meant to be doing the same
thing. I will have a good read to your suggestions and get back. The
key issue is you can not tell Prolog if P is a list, follow these
rules else follow some others, correct?
Correct when P is a variable. If P is even partially instantiated,
unification may provide a way, but things can get confusing, which
I tried to demonstrate.
The situation is different in a typed setting, where P would be
known to be a list or not, even when uninstantiated. That does not
apply to Prolog. I would worry about readability even if it did.
Those two predicates are not really doing the same thing.
.
- References:
- Prolog type overloading
- From: George
- Re: Prolog type overloading
- From: Jussi Piitulainen
- Re: Prolog type overloading
- From: Lekeas GK
- Prolog type overloading
- Prev by Date: Re: Prolog type overloading
- Next by Date: Re: Prolog type overloading
- Previous by thread: Re: Prolog type overloading
- Next by thread: Re: Prolog type overloading
- Index(es):
Relevant Pages
|
|