Non capisco perché dai seguenti due esempi, il primo restituisce il valore corretto (1), mentre il secondo restituisce (). Mi sarei aspettato il risultato (:key) o un'eccezione che non riesce a trovare la soluzione, ma non una lista vuota.unificazione core.logic corrisponde valore nella mappa ma non chiave
(l/run* [q]
(l/== {:key 1} {:key q}))
;; BUT IT DOESNT WORK
(l/run* [q]
(l/== {:key 1} {q 1}))
io non l'ho trovato documentato come un comportamento previsto o no, ma guardando il source code, dalla mia comprensione (limitato), sembra che l'unificazione delle mappe accade solo con i valori, non chiavi.
Come implementato in unify-with-map*, quando core.logic trova la chiave :key nella prima mappa, sembra il suo valore nel secondo, non lo trova, e così balle sulla unificazione. Poiché non ci sono soluzioni, come ha affermato @Arthur Ulfeldt, si finisce con ().
Un limite di 'core.logic' in questo caso? Ma una persona di cui essere consapevole;) La mia sensazione è che se si estende lo spazio di ricerca per includere le chiavi, probabilmente si ottiene più lavoro da fare, quindi potrebbe avere a che fare con un compromesso in termini di prestazioni. Con mia sorpresa, "nessuna soluzione" in 'core.logic' può solo significare che non può risolverlo anche se esiste una soluzione. Quindi "nessuna soluzione" non è una garanzia. Ma ancora abbastanza potente può unificare i valori e questo è probabilmente quello che userete comunque la maggior parte delle volte. – shaft
Sì, questo è corretto. Le chiavi della mappa non possono essere lvars. Potrebbe non essere molto documentato, ma quello era il modo in cui è stata progettata la funzionalità. –
run * restituisce un elenco di soluzioni così() significa nessuna soluzione –
Accetto, ma a mio avviso c'è una soluzione. Se usi 'q =: key', non soddisfa l'equazione? Penso che dovremmo leggere la risposta come: "Impossibile trovare una soluzione" piuttosto che "Posso garantire che non esiste alcuna soluzione". – shaft