quot;])
>
> (ns yo (:refer-clojure :exclude [==]) (:use [clojure.core.logic]))
>
>
> (defne a-to-b [x y]
> ([ {:a {:b b :c c}} [b [c]] ]))
>
>
> (run* [a]
> (a-to-b a [1 [2]]))
>
> ;#=> ({:a {:b 1, :c 2}})
>
>
>
> On 13 July 2015 at 11:47, Gary Ve
{:b 1, :c 2}})
On 13 July 2015 at 11:47, Gary Verhaegen wrote:
> I have not used it. I'm mentioning it because you mentioned unification
> and prolog and because you basically want a two-way function, which is what
> was touted as the ideal use-case for core.logic when it was heavily
I have not used it. I'm mentioning it because you mentioned unification and
prolog and because you basically want a two-way function, which is what was
touted as the ideal use-case for core.logic when it was heavily discussed
on this list a few months (years?) ago.
I'm not aware of the
I haven't.
Are you just suggesting it because I mentioned unification, or have you
used it and know that it might be a good fit ?
Thanks,
Jules
On Monday, 13 July 2015 10:37:55 UTC+1, Gary Verhaegen wrote:
>
> Have you already looked at core.logic?
>
> On Monday, 13 July 20
le src.
>>
>> Ideally it would allow me to extend it to construct/destructure e.g.
>> joda-time class instances etc as some of my internal rep uses these.
>>
>> It feels a bit like unification in PROLOG...
>>
>> Looking forward to hearing your ideas.
>>
the future.
>>
>> My question - Is there a library that will allow me to define the
>> relationship between the two representations declaratively and then
>> generate the transform functions from that single src.
>>
>> Ideally it would allow me to extend it to constr
s from that single src.
>
> Ideally it would allow me to extend it to construct/destructure e.g.
> joda-time class instances etc as some of my internal rep uses these.
>
> It feels a bit like unification in PROLOG...
>
> Looking forward to hearing your ideas.
>
> regards
single src.
Ideally it would allow me to extend it to construct/destructure e.g.
joda-time class instances etc as some of my internal rep uses these.
It feels a bit like unification in PROLOG...
Looking forward to hearing your ideas.
regards,
Jules
--
You received this message because you are
tom?
>
Oversight. I added Datomic support more as a guide then anything serious.
It's up to the community to take it further. Patches welcome!
> 2. Why aren't multimethods used for dispatching to the appropriate
> unification implementation?
>
> -austin
>
Speed.
David
--
Thanks! I had just finished making similar changes. It was a good exercise and
I'm glad to be able to compare code.
A couple of questions:
1. Why is there no case for unifying a Datom with another Datom?
2. Why aren't multimethods used for dispatching to the appropriate u
I've updated the experimental core.logic Datomic support so that you can
unify PersistentVector and Datoms again. In a real system I'd probably
recommend providing your own tuple type that does not implement Sequential
for doing unification with Datoms.
David
On Tue, Jan 8, 2013 a
ke PersistentVector work well enough for
> your use case?
>
> David
>
>
> On Tue, Jan 8, 2013 at 2:01 AM, Austin Haas wrote:
>
> >
> > The datomic unification code in core.logic has bit-rotted. It depends on
> > IUnifyWithSequential, which was removed i
t; The datomic unification code in core.logic has bit-rotted. It depends on
> IUnifyWithSequential, which was removed in this commit:
> https://github.com/clojure/core.logic/commit/bbc4e820128d5a0745ce3d79cd3bbd9401a1bf55
>
> I'm trying to understand how to update the co
The datomic unification code in core.logic has bit-rotted. It depends on
IUnifyWithSequential, which was removed in this commit:
https://github.com/clojure/core.logic/commit/bbc4e820128d5a0745ce3d79cd3bbd9401a1bf55
I'm trying to understand how to update the code, but I don'
On Jan 22, 8:16 pm, David Nolen wrote:
> On Sat, Jan 22, 2011 at 2:09 PM, rb wrote:
> > On Jan 21, 11:41 pm, Alex Baranosky
> > wrote:
> > > Hi,
>
> > > I've read a bit about clojure.core.unify (
> >http://blog.fogus.me/2010/12/14/unification
On Sat, Jan 22, 2011 at 2:09 PM, rb wrote:
> On Jan 21, 11:41 pm, Alex Baranosky
> wrote:
> > Hi,
> >
> > I've read a bit about clojure.core.unify (
> http://blog.fogus.me/2010/12/14/unification-versus-pattern-matching-t...
> > )
> >
> &g
On Sat, Jan 22, 2011 at 2:09 PM, rb wrote:
> I'm not sure dataflow variables are available in clojure though, but
> would be happy to stand corrected (I heard about the contrib dataflow
> module, but from what I read it's more like cells updating based on
> upstream cells it depends on, whereas wh
On Jan 21, 11:41 pm, Alex Baranosky
wrote:
> Hi,
>
> I've read a bit about clojure.core.unify
> (http://blog.fogus.me/2010/12/14/unification-versus-pattern-matching-t...
> )
>
> I haven't gotten through PAIP yet, but I gather unification libraries enable
> l
{X->A,V->Y, Z->b}...
and so on.
Prolog alternates branching point with an unification of the goal and
the result of the rules
(and of course backtracking)
Hopes that helps a bit,
Nicolas.
--
You received this message because you are subscribed to the Google
Groups "Clojure"
On Jan 22, 10:02 pm, David Nolen wrote:
> On Fri, Jan 21, 2011 at 11:41 PM, Alex Baranosky <
>
> alexander.barano...@gmail.com> wrote:
> > Hi,
>
> > I've read a bit about clojure.core.unify (
> >http://blog.fogus.me/2010/12/14/unification-versus-pa
On Fri, Jan 21, 2011 at 11:41 PM, Alex Baranosky <
alexander.barano...@gmail.com> wrote:
> Hi,
>
> I've read a bit about clojure.core.unify (
> http://blog.fogus.me/2010/12/14/unification-versus-pattern-matching-to-the-death/
> )
>
> I haven't gotten throu
Hi,
I've read a bit about clojure.core.unify (
http://blog.fogus.me/2010/12/14/unification-versus-pattern-matching-to-the-death/
)
I haven't gotten through PAIP yet, but I gather unification libraries enable
logic programming? Is it true that unification is a superset of patter
22 matches
Mail list logo
