Wow! I say that because that might be getting closer to what I have in mind but still not there yet. I'm really trying to develop a type which honors two interfaces, one for the list object, and one for the IEvaluable object.
As a type, I invoke it, then add objects to it, then place it, as an IEvaluable object inside another such collection. Perhaps it is the first - root - which begins an and/or network of IEvaluable objects, some of which are the workers which go outside and make computations before returning their boolean. But, I have been wandering down another rabbit hole, the one where I ignore list comprehensions and proxy an ArrayList. I have code which almost runs, but which is far from perfect. I created a gist which exposes my current experiment - which is close, but no cigars yet. https://gist.github.com/KnowledgeGarden/004fd93a78e2238c878b585f158759f9 Thanks Jack On Fri, Aug 14, 2020 at 1:38 PM Oleksandr Shulgin < oleksandr.shul...@zalando.de> wrote: > On Fri, Aug 14, 2020 at 8:44 PM Jack Park <jackp...@topicquests.org> > wrote: > >> This idea shows up early in Clojure text books. This concept comes to >> mind rather quickly: >> >> (def and_list (ArrayList.) >> ... >> ) >> >> But, in the end it is an ArrayList which has an interface-defined >> behavior, e.g. boolean eval(); (from Java) >> Thus far, in a tiny VSCode project, I defined >> >> (definterface IEvaluable >> (^boolean runIt [])) >> >> and defined a simple object which will return false and one which will >> return true. I'll use those to populate a conjunctive and a disjunctive >> list. >> >> Now I must define a list object which runs that interface. >> >> Still digging and experimenting, but, on the surface, this approach >> appears to be possible. >> >> From above, as a sketch: >> >> (def and_list (ArrayList.) >> IEvaluable >> (runIt [this] >> <some code to conditionally walk the list>)) >> ) >> >> Meanwhile, I found this https://clojuredocs.org/clojure.core/proxy-super >> which is now on the table to explore. >> > > Nevermind transducers: I've just realized that reduced can be used with > the normal reduce. E.g. here's short-circuiting AND-reduction fn: > > (defn andr > ([] true) > ([i] i) > ([r i] (let [o (and r i)] > (if o > o > (reduced o))))) > > When it comes to the actual lists, it depends how you'd like to represent > them. E.g. I could imagine something like the following can be a useful > notation: > > [:and 1 2 [:or 3 4] 5] > > or even more direct: > > (quote (and 1 2 (or 3 4) 5)) > > If you really want an interface-like look and feel, then protocols might > be the right answer: > > (defprotocol Evaluable > (evaluate [this])) > > (defrecord AndList [items] > Evaluable > (evaluate [this] > (reduce andr (:items this)))) > > user> (evaluate (->AndList [1 2 3])) > 3 > user> (evaluate (->AndList [1 false 3])) > false > > To complete it, you'll need to add the OrList and sneak (map evaluate) in > the reduce call in both And- and OrList. > > Cheers, > -- > Alex > > On Fri, Aug 14, 2020 at 3:41 AM Jesús Gómez <jgo...@gmail.com> wrote: >> >>> Why not to Java-Interop with that Interface and those Classes directly, >>> the same way you use them in Java? >>> >>> El jue., 13 ago. 2020 a las 22:54, Jack Park (<jackp...@topicquests.org>) >>> escribió: >>> >>>> The problem: >>>> >>>> In Java, I have an interface *IInferrable* which is basically boolean >>>> eval(); >>>> >>>> Any Java object which extends IInferrable, no matter what it is, will >>>> answer to eval() and return a boolean. >>>> The idea lies at the heart of an inference engine. >>>> >>>> But, I also define a class *AndList* which implements IInferrable and >>>> extends java.util.ArrayList<Inferrable> >>>> >>>> So, AndList, and its sibling OrList behave just like a List object, but >>>> also will answer to eval() by running the collection and dealing with what >>>> each element returns when it, too, is eval()'d. >>>> >>>> I'd really love to discover how to pull that off in Clojure. >>>> >>>> Many thanks in advance. -Jack >>>> >>> -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/clojure/CACACo5Rj3U1CJdEy431j7EBpR4oOVccKoGtLjCRPdiKd%3DvgLTQ%40mail.gmail.com > <https://groups.google.com/d/msgid/clojure/CACACo5Rj3U1CJdEy431j7EBpR4oOVccKoGtLjCRPdiKd%3DvgLTQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/CAH6s0fz8sf3JR_9qrf1eee5d%2Bpp166RkKrniuzKm-kC968fotA%40mail.gmail.com.
