cancer():-
pain(strong),
mood(depressed),
fever(mild),
bowel(bloody),
miscellaneous(giddy).
diagnose():-
nl,
cancer()->write("has cancer").
예를 들어 dog (X)는 X가 개라고 말하지만 암 진단서는 다음 조건이 충족되는지 여부를 확인합니다. 그렇게 할 수있는 더 좋은 방법이 있습니까?선언적 프로그래밍 또는 프롤로그 철학에 대한 변수를 전달하지 않고 규칙을 수행합니까?
프롤로그, 어떤 인수가없는 조건 순수 에서만 성공하거나 ( 전혀 종료 여부) 실패 할 수 있습니다.
따라서 매우 적은 정보 만 인코딩 할 수 있습니다. 항상 이 성공한 조건자인은 이미 사용 가능합니다. true/0, 즉 인수가 있습니다. 이 항상로 실패하는 술어도 이미 사용 가능합니다. 즉 false/0이며 0이 인수입니다. 결코 가 끝나는 술어는 쉽게 끝날 수있다.
이 의미에서, 당신은 제로 논증으로 더 많은 술어를 필요로하지 않으며 당신은 그러한 술어에 대해 의심 스러울 때 완벽하게 정당화된다고 생각합니다.
제로 인수가있는 술어는 매우 구체적이므로 제한적으로 사용됩니다. 그러나, 예를 들어 고정 된 세트의 테스트를 설명하거나, 부작용 인에만 유용 할 수 있습니다. 이것은 또한 당신이 사용하고있는 것입니다, 에 의해 출력은 술어가 성공했을 때 터미널에서 출력됩니다.
이것은 Prolog의 순수 하위 집합을 떠나고 순수한 논리를 넘어서는 기능에 의존한다는 것을 의미합니다.
이것은 일반적으로 매우 나쁜 생각입니다
따라서, 당신의 쓰기 프로그램을 가정 해
cancer(Patient):-
patient_pain(Patient, strong),
patient_mood(Patient, depressed),
patient_fever(Patient, mild),
patient_bowel(Patient, bloody),
patient_miscellaneous(Patient, giddy).
을이 술어는 환자가을 매개 변수화 지금 , 따라서 훨씬 더 많은 일반 사용자가 게시 한 것보다.
지금에 대한 여러 환자을 추론 할 수 있습니다, 당신이 등 조건
을 테스트을 프롤로그 쿼리를 사용할 수 있습니다, 다른 환자에 대한 병렬 에 을 추론 할 수 있습니다예를 들어 patient_diagnosis/2을 정의하여 모든 것을 완전하게 유지하고 위의 이점으로부터 이익을 얻음으로써 술어를 더 일반화 할 수 있습니다. 환자는 몇 가지 질병을 앓고있을 수 있으며, 이는 에서 되돌릴 수 있습니다..
따라서 : 예, 인수가없는 규칙은 실제 코드에서 발생하면 의심 스럽거나 비정형 적입니다. " case"와 "consistency check"와 같은 시나리오는 제외하고 부작용에만 유용 할 수 있으며 가능한 경우 부작용을 피하는 것이 좋습니다.
이 항목에 대한 자세한 내용은 logical-purity을 참조하십시오.
cancer()은 유효 구문이지만 아이디어는 완벽합니다.
그냥
cancer
로 전화를하고 사실 또는 규칙으로 정의한다.
cancer. % fact
cancer :- blah blah %rule
사실, 당신은 당신의 프로그램없이 인수와 시스템 술어를 사용 -
nl이 항상 성공 술어이며, 개행 문자를 출력합니다.
인수가없는 조건자를 사용하는 데는 여러 가지 이유가 있습니다. 프로덕션 환경에서 개발 환경과 약간 다른 환경에서 실행되는 서버가 있다고 가정 해보십시오. 프로덕션 환경에서 개발자 액세스 API가 해제되었습니다. 우리는 개발 환경
에있어 또는 부작용이 출발, 또는 상태를 사용하고있는 경우
my_handler(Request) :-
development,
blah blah
개발에만 성공합니다.