Re: Strange Vector failure

[Jack Park]

Cora,

That's simply amazing. I added one more "or" test: all-false.

I confess, I'm not yet at the place where I look at that pattern and
recognize it, but, thanks  to you and to the other hints I received here, I
now have something to work with.

Next up for me will be to test the "not" functions.

Many thanks!

-Jack

On Fri, Jul 23, 2021 at 6:03 PM Cora Sutton  wrote:

> You can stay away from eval unless you have extremely special needs,
> really. I never use it myself. The evaluate-or-fns and evaluate-and-fns
> don't care what the function is, it could be another call to
> evaluate-or-fns or evaluate-and-fns, and in this way you can recurse as
> deeply as you desire and only evaluate when you actually want values out of
> it.
>
> (defn evaluate-and-fns
>   "Returns true if every function in members returns a value that is
> true-ish according to Clojure's
>   truthiness rules. Otherwise returns false."
>   [members]
>   (every? (fn [member]
> (member))
>   members))
>
> (defn evaluate-or-fns
>   "Returns true if any function in members returns a value that is
> true-ish according to Clojure's
>   truthiness rules. Otherwise returns false."
>   [members]
>   (boolean
>(some (fn [member]
>(member))
>  members)))
>
> (evaluate-or-fns [(fn []
> (evaluate-and-fns [(fn [] (evaluate-and-fns
> [simple-true-fn simple-true-fn]))
>simple-true-fn]))
>   (fn []
> (evaluate-and-fns [simple-true-fn simple-false-fn]))])
>
> On Fri, Jul 23, 2021 at 7:22 PM Jack Park 
> wrote:
>
>> Hello again, Cora (and list!)
>>
>> I have your gist running, then added a new feature
>>
>> https://gist.github.com/KnowledgeGarden/330b4147cd3d4909ef55684fc4c1f00d
>>
>> The first code was for conjunctive lists, I added disjunctive lists
>>
>> There, I started with some? but could not make the grade, ended up with
>> some fn where fn is eval. That's the code.
>> It's behaving strangely, but maybe I'm on the right track.
>>
>> Where this is going is that a list can be populated with things other
>> than simple functions like SimpleTrue; can be populated with conjunctive
>> and disjunctive lists, each of which can be similarly populated. That, of
>> course, means that evaluating a single inferrable list is the same as
>> walking a possibly complex (no loops, hopefully) spider web.
>>
>> Thanks
>> Jack
>>
>> On Mon, Jul 19, 2021 at 6:04 PM Cora Sutton  wrote:
>>
>>> Hello again, Jack. I'm not sure what your code looked like before or
>>> looks like now but I think maybe a different way of helping you out with
>>> this is in order. Here's some code that does what I think you're going for
>>> and runs:
>>>
>>> https://gist.github.com/corasaurus-hex/1c86b545644b734310a15d984f61ad99
>>>
>>> Have a look, play with it a bit, change around value and see what
>>> breaks. Hope that's helpful!
>>>
>>> On Mon, Jul 19, 2021 at 5:55 PM Jack Park 
>>> wrote:
>>>
 Did. That suggestion was made earlier. Did not change anything.

 Here's a test which ran just fine
 (def x (evaluate_and (list true true)))
   (println "A" x)
   (def y (evaluate_and (list true false)))
   (println "B" y)

 But, the moment I attempt to make a list with two functions in it, the
 code breaks and returns - without any errors - not a boolean, but the
 structure I passed it.


 On Mon, Jul 19, 2021 at 3:43 PM Cora Sutton  wrote:

> Those are functions that call booleans as functions. Try this:
>
> (defn simple-true [] true)
>
> On Mon, Jul 19, 2021 at 5:41 PM Jack Park 
> wrote:
>
>> Great points!
>> They are filled with functions which look like this
>>
>> (defn simple_true [] (true))
>>
>> They are not booleans but functions which return a boolean.
>> Here is a list of two of those as produced by the code:
>>
>> (#object[ie4clj.Tests$simple_false 0x3a4621bd
>> ie4clj.Tests$simple_false@3a4621bd]
>>  #object[ie4clj.Tests$simple_false 0x3a4621bd
>> ie4clj.Tests$simple_false@3a4621bd])
>>
>> Or maybe I missed something.
>>
>> On Mon, Jul 19, 2021 at 3:33 PM Cora Sutton  wrote:
>>
>>> Your members list needs to be filled with things that can be called
>>> as functions, since that's what that code snippet does, and booleans
>>> definitely cannot be called as functions. That's what the error means,
>>> there's a boolean in your list and it's trying to cast it to an IFn (a
>>> Clojure function interface) when it is called as (member).
>>>
>>> Can you show the lists you construct? Are they full of functions
>>> that take no arguments? Do you want the lists to be able to contain
>>> booleans too?
>>>
>>> On Mon, Jul 19, 2021 at 2:57 PM Jack Park 
>>> wrote:
>>>
 Cora

 (every? (fn [member] (member)) members)
 works 

Re: Strange Vector failure

[Cora Sutton]

You can stay away from eval unless you have extremely special needs,
really. I never use it myself. The evaluate-or-fns and evaluate-and-fns
don't care what the function is, it could be another call to
evaluate-or-fns or evaluate-and-fns, and in this way you can recurse as
deeply as you desire and only evaluate when you actually want values out of
it.

(defn evaluate-and-fns
  "Returns true if every function in members returns a value that is
true-ish according to Clojure's
  truthiness rules. Otherwise returns false."
  [members]
  (every? (fn [member]
(member))
  members))

(defn evaluate-or-fns
  "Returns true if any function in members returns a value that is true-ish
according to Clojure's
  truthiness rules. Otherwise returns false."
  [members]
  (boolean
   (some (fn [member]
   (member))
 members)))

(evaluate-or-fns [(fn []
(evaluate-and-fns [(fn [] (evaluate-and-fns
[simple-true-fn simple-true-fn]))
   simple-true-fn]))
  (fn []
(evaluate-and-fns [simple-true-fn simple-false-fn]))])

On Fri, Jul 23, 2021 at 7:22 PM Jack Park  wrote:

> Hello again, Cora (and list!)
>
> I have your gist running, then added a new feature
>
> https://gist.github.com/KnowledgeGarden/330b4147cd3d4909ef55684fc4c1f00d
>
> The first code was for conjunctive lists, I added disjunctive lists
>
> There, I started with some? but could not make the grade, ended up with
> some fn where fn is eval. That's the code.
> It's behaving strangely, but maybe I'm on the right track.
>
> Where this is going is that a list can be populated with things other than
> simple functions like SimpleTrue; can be populated with conjunctive and
> disjunctive lists, each of which can be similarly populated. That, of
> course, means that evaluating a single inferrable list is the same as
> walking a possibly complex (no loops, hopefully) spider web.
>
> Thanks
> Jack
>
> On Mon, Jul 19, 2021 at 6:04 PM Cora Sutton  wrote:
>
>> Hello again, Jack. I'm not sure what your code looked like before or
>> looks like now but I think maybe a different way of helping you out with
>> this is in order. Here's some code that does what I think you're going for
>> and runs:
>>
>> https://gist.github.com/corasaurus-hex/1c86b545644b734310a15d984f61ad99
>>
>> Have a look, play with it a bit, change around value and see what breaks.
>> Hope that's helpful!
>>
>> On Mon, Jul 19, 2021 at 5:55 PM Jack Park 
>> wrote:
>>
>>> Did. That suggestion was made earlier. Did not change anything.
>>>
>>> Here's a test which ran just fine
>>> (def x (evaluate_and (list true true)))
>>>   (println "A" x)
>>>   (def y (evaluate_and (list true false)))
>>>   (println "B" y)
>>>
>>> But, the moment I attempt to make a list with two functions in it, the
>>> code breaks and returns - without any errors - not a boolean, but the
>>> structure I passed it.
>>>
>>>
>>> On Mon, Jul 19, 2021 at 3:43 PM Cora Sutton  wrote:
>>>
 Those are functions that call booleans as functions. Try this:

 (defn simple-true [] true)

 On Mon, Jul 19, 2021 at 5:41 PM Jack Park 
 wrote:

> Great points!
> They are filled with functions which look like this
>
> (defn simple_true [] (true))
>
> They are not booleans but functions which return a boolean.
> Here is a list of two of those as produced by the code:
>
> (#object[ie4clj.Tests$simple_false 0x3a4621bd
> ie4clj.Tests$simple_false@3a4621bd]
>  #object[ie4clj.Tests$simple_false 0x3a4621bd
> ie4clj.Tests$simple_false@3a4621bd])
>
> Or maybe I missed something.
>
> On Mon, Jul 19, 2021 at 3:33 PM Cora Sutton  wrote:
>
>> Your members list needs to be filled with things that can be called
>> as functions, since that's what that code snippet does, and booleans
>> definitely cannot be called as functions. That's what the error means,
>> there's a boolean in your list and it's trying to cast it to an IFn (a
>> Clojure function interface) when it is called as (member).
>>
>> Can you show the lists you construct? Are they full of functions that
>> take no arguments? Do you want the lists to be able to contain booleans 
>> too?
>>
>> On Mon, Jul 19, 2021 at 2:57 PM Jack Park 
>> wrote:
>>
>>> Cora
>>>
>>> (every? (fn [member] (member)) members)
>>> works fine on [constantly true & false
>>> but fails with
>>> java.lang.Boolean cannot be cast to clojure.lang.IFn
>>> on the lists I construct.
>>>
>>> In truth, I thought all the code was working, but that turned out ot
>>> be an artifact of the test I designed. When I changed the test 
>>> conditions,
>>> evaluate_and failed.
>>>
>>>
>>> On Sun, Jul 18, 2021 at 5:00 PM Cora Sutton  wrote:
>>>
 Hello again Jack,

 On Sun, Jul 18, 2021 at 6:21 PM Jack Park 

Re: Strange Vector failure

[Jack Park]

Hello again, Cora (and list!)

I have your gist running, then added a new feature

https://gist.github.com/KnowledgeGarden/330b4147cd3d4909ef55684fc4c1f00d

The first code was for conjunctive lists, I added disjunctive lists

There, I started with some? but could not make the grade, ended up with
some fn where fn is eval. That's the code.
It's behaving strangely, but maybe I'm on the right track.

Where this is going is that a list can be populated with things other than
simple functions like SimpleTrue; can be populated with conjunctive and
disjunctive lists, each of which can be similarly populated. That, of
course, means that evaluating a single inferrable list is the same as
walking a possibly complex (no loops, hopefully) spider web.

Thanks
Jack

On Mon, Jul 19, 2021 at 6:04 PM Cora Sutton  wrote:

> Hello again, Jack. I'm not sure what your code looked like before or looks
> like now but I think maybe a different way of helping you out with this is
> in order. Here's some code that does what I think you're going for and runs:
>
> https://gist.github.com/corasaurus-hex/1c86b545644b734310a15d984f61ad99
>
> Have a look, play with it a bit, change around value and see what breaks.
> Hope that's helpful!
>
> On Mon, Jul 19, 2021 at 5:55 PM Jack Park 
> wrote:
>
>> Did. That suggestion was made earlier. Did not change anything.
>>
>> Here's a test which ran just fine
>> (def x (evaluate_and (list true true)))
>>   (println "A" x)
>>   (def y (evaluate_and (list true false)))
>>   (println "B" y)
>>
>> But, the moment I attempt to make a list with two functions in it, the
>> code breaks and returns - without any errors - not a boolean, but the
>> structure I passed it.
>>
>>
>> On Mon, Jul 19, 2021 at 3:43 PM Cora Sutton  wrote:
>>
>>> Those are functions that call booleans as functions. Try this:
>>>
>>> (defn simple-true [] true)
>>>
>>> On Mon, Jul 19, 2021 at 5:41 PM Jack Park 
>>> wrote:
>>>
 Great points!
 They are filled with functions which look like this

 (defn simple_true [] (true))

 They are not booleans but functions which return a boolean.
 Here is a list of two of those as produced by the code:

 (#object[ie4clj.Tests$simple_false 0x3a4621bd
 ie4clj.Tests$simple_false@3a4621bd]
  #object[ie4clj.Tests$simple_false 0x3a4621bd
 ie4clj.Tests$simple_false@3a4621bd])

 Or maybe I missed something.

 On Mon, Jul 19, 2021 at 3:33 PM Cora Sutton  wrote:

> Your members list needs to be filled with things that can be called as
> functions, since that's what that code snippet does, and booleans
> definitely cannot be called as functions. That's what the error means,
> there's a boolean in your list and it's trying to cast it to an IFn (a
> Clojure function interface) when it is called as (member).
>
> Can you show the lists you construct? Are they full of functions that
> take no arguments? Do you want the lists to be able to contain booleans 
> too?
>
> On Mon, Jul 19, 2021 at 2:57 PM Jack Park 
> wrote:
>
>> Cora
>>
>> (every? (fn [member] (member)) members)
>> works fine on [constantly true & false
>> but fails with
>> java.lang.Boolean cannot be cast to clojure.lang.IFn
>> on the lists I construct.
>>
>> In truth, I thought all the code was working, but that turned out ot
>> be an artifact of the test I designed. When I changed the test 
>> conditions,
>> evaluate_and failed.
>>
>>
>> On Sun, Jul 18, 2021 at 5:00 PM Cora Sutton  wrote:
>>
>>> Hello again Jack,
>>>
>>> On Sun, Jul 18, 2021 at 6:21 PM Jack Park 
>>> wrote:
>>>
 (every? eval members)  does not appear to work on a list of
 functions designed to evaluate to a boolean.

>>>
>>> If members is a list of functions then you would do:
>>>
>>> (every? (fn [member] (member)) members)
>>>
>>> Showing it work here:
>>>
>>> (every? (fn [member] (member)) [(constantly true) (constantly true)])
>>> ;; => true
>>> (every? (fn [member] (member)) [(constantly true) (constantly
>>> false)])
>>> ;; => false
>>>
>>>
 That code is used in a function evaluateAnd

 Two simple tests
 (evaluateAnd [true true] --> true
 (evaluateAnd [true false] --> nil (why not "false" as the every?
 examples show?)

>>>
>>> In Clojure things are either "truthy" or "falsey", and the only
>>> "false" values are false and nil so returning nil is usually fine.
>>> Everything else is "truthy". I wouldn't worry about it returning nil 
>>> since
>>> other things were broken anyways.
>>>
>>> https://clojure.org/guides/learn/flow#_truth
>>>
>>>
 The specific code for building the list of functions is this

 (def x (atom []))
   (let [result (list (ref SimpleTrue) (ref 

Re: Strange Vector failure

[Jack Park]

Ok. I got back to this, now running Cora's gist. It gives me a different
place to explore these issues.
More soon.
Jack

On Tue, Jul 20, 2021 at 5:31 PM Jack Park  wrote:

> Hi Cora,
>
> I got dragged away but plan to study your contribution, which I deeply
> appreciate.
>
> My project plans to be a very simple clojure re-implementation of an
> inference engine I wrote in Forth more than 20 years ago, a kind of list
> processor in which you have an interface which advertises a simple
> "eval"-like method, applicable to structures as well as atoms. Thus,
> conjunctive and disjunctive lists, plus not, all of which can be populated
> with combinations of those and atoms, tiny computational objects which do
> stuff within the same interface. Atoms can ask questions at the UI, do
> computations on databases, and so forth.
>
> I benchmarked that against a more traditional symbolic (frame-based)
> inference I had written to control autoclaves for curing polymer resins - a
> contract for the military which ended up helping to fix fighter jets which
> were grounded because of bird impacts penetrating composite leading edges
> and crashing - we were able to cure improved leading edges; the new code
> executed more than 10 times faster than the old symbolic code. That was
> then (Forth), this is now (Java/Clojure). I've done it in Java. Now it's
> time to use that as a learning exercise.
>
> Many thanks
> Jack
>
> On Mon, Jul 19, 2021 at 6:04 PM Cora Sutton  wrote:
>
>> Hello again, Jack. I'm not sure what your code looked like before or
>> looks like now but I think maybe a different way of helping you out with
>> this is in order. Here's some code that does what I think you're going for
>> and runs:
>>
>> https://gist.github.com/corasaurus-hex/1c86b545644b734310a15d984f61ad99
>>
>> Have a look, play with it a bit, change around value and see what breaks.
>> Hope that's helpful!
>>
>> On Mon, Jul 19, 2021 at 5:55 PM Jack Park 
>> wrote:
>>
>>> Did. That suggestion was made earlier. Did not change anything.
>>>
>>> Here's a test which ran just fine
>>> (def x (evaluate_and (list true true)))
>>>   (println "A" x)
>>>   (def y (evaluate_and (list true false)))
>>>   (println "B" y)
>>>
>>> But, the moment I attempt to make a list with two functions in it, the
>>> code breaks and returns - without any errors - not a boolean, but the
>>> structure I passed it.
>>>
>>>
>>> On Mon, Jul 19, 2021 at 3:43 PM Cora Sutton  wrote:
>>>
 Those are functions that call booleans as functions. Try this:

 (defn simple-true [] true)

 On Mon, Jul 19, 2021 at 5:41 PM Jack Park 
 wrote:

> Great points!
> They are filled with functions which look like this
>
> (defn simple_true [] (true))
>
> They are not booleans but functions which return a boolean.
> Here is a list of two of those as produced by the code:
>
> (#object[ie4clj.Tests$simple_false 0x3a4621bd
> ie4clj.Tests$simple_false@3a4621bd]
>  #object[ie4clj.Tests$simple_false 0x3a4621bd
> ie4clj.Tests$simple_false@3a4621bd])
>
> Or maybe I missed something.
>
> On Mon, Jul 19, 2021 at 3:33 PM Cora Sutton  wrote:
>
>> Your members list needs to be filled with things that can be called
>> as functions, since that's what that code snippet does, and booleans
>> definitely cannot be called as functions. That's what the error means,
>> there's a boolean in your list and it's trying to cast it to an IFn (a
>> Clojure function interface) when it is called as (member).
>>
>> Can you show the lists you construct? Are they full of functions that
>> take no arguments? Do you want the lists to be able to contain booleans 
>> too?
>>
>> On Mon, Jul 19, 2021 at 2:57 PM Jack Park 
>> wrote:
>>
>>> Cora
>>>
>>> (every? (fn [member] (member)) members)
>>> works fine on [constantly true & false
>>> but fails with
>>> java.lang.Boolean cannot be cast to clojure.lang.IFn
>>> on the lists I construct.
>>>
>>> In truth, I thought all the code was working, but that turned out ot
>>> be an artifact of the test I designed. When I changed the test 
>>> conditions,
>>> evaluate_and failed.
>>>
>>>
>>> On Sun, Jul 18, 2021 at 5:00 PM Cora Sutton  wrote:
>>>
 Hello again Jack,

 On Sun, Jul 18, 2021 at 6:21 PM Jack Park 
 wrote:

> (every? eval members)  does not appear to work on a list of
> functions designed to evaluate to a boolean.
>

 If members is a list of functions then you would do:

 (every? (fn [member] (member)) members)

 Showing it work here:

 (every? (fn [member] (member)) [(constantly true) (constantly
 true)])
 ;; => true
 (every? (fn [member] (member)) [(constantly true) (constantly
 false)])
 ;; => false

Clojurists Together funding applications are open for Q3 2020

[Daniel Compton]

Hi folks

You know the drill, Clojurists Together  
is funding open source Clojure tools, libraries, and documentation. 
Applications are open until 6th August, 2021, midnight PST.

Our members would like us 
 to focus 
on developer tools, so if you work on Clojure developer tools, please apply 
!

There's a few changes this time around. You can see the full details on the 
announcement 
,
 
but briefly:

   - People now apply for $1k/$2k experimental/small projects, or $9k 
   larger projects
   - Funding can now be taken over 1-12 months, instead of only over 3 
   months
   - You have 2 months to start after you get selected to give you time to 
   prepare

We're also doing a new type of long-term funding where our members will 
vote on developers to receive $1.5k/month for 12 months. The recipients 
won't have any specific requirements, they'll just keep doing the great 
work they're already doing.

We currently have the funds to support 3 developers for long-term 
fellowships, but we'd like to get to 6. To do so we’ll need new developer 
and company members to help support this. If you’re a company that relies 
on Clojure, please consider joining Clojurists Together.

Thanks, Daniel.

-- 
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/eb40f22f-4bb8-4b1b-b749-c398cb438d25n%40googlegroups.com.