क्लोजर के `core.logic`

Question

The following Clojure code में लक्ष्य आदेश दो अलग-अलग आदेशों में समान लक्ष्यों के साथ समान तर्क समस्या को हल करने के लिए core.logic का उपयोग करता है। ऑर्डर करने का यह विकल्प एक को जल्दी खत्म करने का कारण बनता है और दूसरा लटकता है।

(use `clojure.core.logic) 

;; Runs quickly. Prints (1 2 3). 
(clojure.pprint/pprint (run* [q] (fresh [x] (== x [1,2,3]) 
              (membero q x)))) 

;; Hangs 
(clojure.pprint/pprint (run* [q] (fresh [x] (membero q x) 
              (== x [1,2,3])))) 

क्या इस समस्या से बचने के लिए कोई सामान्य समाधान या सामान्य अभ्यास है?

core.logic के साथ, आप जितनी जल्दी हो सके खोज अंतरिक्ष को कम करना चाहते:

Answer 1

यदि आप membero का उपयोग करने जा रहे हैं तो इस समस्या का कोई सामान्य समाधान नहीं है। ताजा वर्र्स के साथ membero पर कॉल करने से यह सभी (पढ़ने, अनंत) संभावित सूचियां उत्पन्न कर सकता है जिसके लिए q सदस्य है। बेशक 3 से बड़े सूचियां लागू नहीं होती हैं - लेकिन चूंकि आपने run* का उपयोग किया है, इसलिए यह गिनती से 3 की तुलना में बड़ी सूचियों की कोशिश कर रहा है, भले ही प्रत्येक विफल हो जाए।

बाधा बुनियादी ढांचे का उपयोग करके core.logic के नए संस्करणों में membero का बेहतर संस्करण लिखना संभव है, लेकिन आने वाले महीनों में यह कैसे हो सकता है इसका विवरण बदल सकता है। बाधाओं को परिभाषित करने के लिए एक ठोस सार्वजनिक एपीआई होने तक आप प्रोलॉग को परेशान करने वाले सूक्ष्म क्रम और गैर-समाप्ति के मुद्दों से फंस गए हैं।

Answer 2

यहाँ मेरी समझ है। यदि आप पहले membero बाधा डालते हैं, तो रन membero स्थान, और == बाधा द्वारा उत्पादित विफलता पर बैकट्रैक खोजकर शुरू होगा। लेकिन membero स्थान बहुत बड़ा है, क्योंकि न तो q और न ही x एकीकृत या कम से कम बाध्य है।

लेकिन अगर आप == बाधा पहले डाल दिया, तो आप सीधे [1 2 3] साथ x को एकजुट, और खोज membero के लिए जगह अब स्पष्ट रूप से x के तत्वों को घिरा है।