Unification to featurec compiler #36
Conversation
This is to prepare for the DSL queries that are coming.
|
I wonder why Travis isn't picking this up... |
|
I am turning it on and off again in the hope that this will make senp^H^H^H^HTravis notice me. |
|
😍 |
Current coverage is
|
|
I removed the |
Builds on top of RackSec#36. Closes RackSec#37.
| (:require [clojure.core.logic :as l])) | ||
| (:require [clojure.core.logic :as l] | ||
| [clojure.core.match :as m] | ||
| [clojure.core.logic.fd :as fd])) |
There was a problem hiding this comment.
This is unused and should be kicked out.
|
The partial coverage is mostly a lie. |
|
I have added that branch test in 1666f22. |
|
I can't tell if codecov.io hasn't updated yet, or if there's another branch I've forgotten about... Either way it certainly looks like I've covered all the interesting cases... |
| (try | ||
| (in-ns 'desdemona.query) | ||
| (eval compiled-query) | ||
| (eval (generate-logic-query n-answers logic-query events)) |
There was a problem hiding this comment.
Is the benefit of moving this here instead of in the let above that it's more lazily evaluated? That it's actually executed inside the right namespace? Or is the functionality identical and it's just for organization?
There was a problem hiding this comment.
It is purely organization.
Closes #29. Builds on top of #27.
I am a little unhappy that I had to specify
:seqall over the place forcore.matchto be happy. I considered termito which does make these rewrite rules simpler, but I'm concerned that they might not quite end up having the features we need, so I'll finish the tickets we have now before I try to rewrite it later. (It does work on top of core.logic, which is nice, because it means we can get rid of a library.)