I am looking for an implementation of state charts (hierarchical state machines)

i am planning to use this in a hobby project

Perhaps this could be used: http://commons.apache.org/proper/commons-scxml/

Also stumbled upon this: https://github.com/klangfarbe/UML-Statechart-Framework-for-Java

thank you for the suggestions @U2FRKM4TW!

i'm new to the Java world, so didn't think to look in that ecosystem

will read through the above. thank you!

It very well might be that there are Clojure libraries - I just didn't find them, so tried looking for Java ones.

got it

https://github.com/lucywang000/clj-statecharts

looks very promising - thank you @U8LB00QMD!

if you don't mind @U8LB00QMD - may I ask how you came to be aware of this?

It was posted in #announcements a couple of months ago and I gave it a star. Haven't had a chance try it out though.

Sometimes the #find-my-lib channel can be helpful for questions like this (but it isn't as populated as this channel).

thank you @U04V70XH6!

Is it possible to see some more code? I am not quite getting the constellation, yet

Maybe you could consider all-sites-available as a precondition for all tests in that ns, not as a test itself. In that case you could run this check with (use-fixtures :once ...) and skip all dependent tests afterwards if it returns false?

Here's the code

(defn wait-for-url-available [url],,,)

(def sites-are-up (atom false)) 
(deftest all-sites-available
  (reset! sites-are-up false)
  (and
   (is (true? (wait-for-url-available url-1)))
   (is (true? (wait-for-url-available url-2)))
   (reset! sites-are-up true)))

(defn test-ns-hook []
  (all-sites-available)
  (when @sites-are-up
    (,,,more-tests-here,,,)))

you have to do that in case your json data contains some string representing encoded json

"{\"key\":\"{\\\"netsed-key\\\":42}\"}"

almost

I am getting, this one below. It parses policy and content correctly. why not the content of :Content (no pun intended:)

{:Policy
   {:Content
      "{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"RestrictAMIs\",\n      \"Effect\": \"Deny\",\n      \"Action\": [\n        \"ec2:RunScheduledInstances\",\n        \"ec2:RunInstances\"\n      ],\n      \"Resource\": \"arn:aws:ec2:*::image/ami-*\",\n      \"Condition\": {\n        \"StringNotEquals\": {\n     
...etc

so yes, that looks like the case I just describe.

It there a way to render it into the map in one go?

I don’t think so. from json specification that is completely valid structure.

yep, that's what I thought, thank you

So you want to be able to compute an arbitrary function at compile time, given a vector of arguments?

If yes, then

(defmacro compile-call [f args]
  (apply (ns-resolve *ns* f) args))
=> #'user/compile-call
(compile-call + [1 2 3])
=> 6
(macroexpand '(compile-call + [1 2 3]))
=> 6

The function is defined, but the arguments should be passed along, not in a []. Eg (corfunc "command" 1 2 4 etc).

In the case when apply cannot be used

The arguments will have to be known at compile-time. So it cannot be e.g. [(inc 1) (inc 2)] since the vector will be quoted.

And why can apply not be used?

apply will work with +, but will it work with  `(corfunc "command" 1 2 4 etc)` , when the arguments are of different type?

Absolutely.

Alright, will have to test. What about getting rid of eval in the original example, when the function is known?

Just call apply?

(apply + vecc).

Or (apply corfunc ["command" 1 2 4 etc]).

yes, it does apply apply to all args. Thanks!

In general if you need to eval you probably made a mistake 😄

How do you call your macro with this funtion, @U2FRKM4TW. It appears to fail

(defn corefunc [one & two]
  {:one one
  :two two})

How did you try calling it?

In all possible ways ) , eg (compile-call corefunc [1 2 3 ])

Which version of the macro did you use exactly?

(defmacro compile-call [f args]
  (apply (ns-resolve *ns* f) args))

Use (macroexpand '(compile-call corefunc [1 2 3]) and see what it outputs. It should become obvious what's wrong. Keep in mind that macros don't always result in plain values - they output new forms to be evaluated.

The error is

(compile-call corefunc ["one" 1 2 3])
; : Cannot call 1 as a function.

{:one "one", :two (2 3)}

It's not hard to debug at all in this case. It doesn't lose 1 on my end:

(macroexpand '(compile-call corefunc ["one" 1 2 3]))
=> {:one "one", :two (1 2 3)}

One way to fix it would be to wrap the usage of two in vec - then (1 2 3) will become [1 2 3], which won't cause any troubles.

And if you need specifically a list in :two and not a vector, you can use (cons list two).

(defn corefunc [one & two]
  {:one one
   :two (cons list two)}

(compile-call corefunc ["one" 1 2 3])
=> {:one "one", :two (1 2 3)}

But if you don't have a very good reason to compute such things in compile time (negligible performance improvement is not a good reason), I'd stick to regular functions instead of macros.

at what point ["one" 1 2 3])) becomes (1 2 3)?

You supply "one" 1 2 3 to a function with an args vector of [one & two]. Upon calling that function, one is assigned the value of "one" and two is assigned the value of (1 2 3).

https://clojure.org/guides/learn/functions#_variadic_functions Such questions about fundamentals are better suited for #beginners

I was sure that 1 2 3 becomes a vector, for some reason )

And it's actually clojure.lang.ArraySeq

Why is it trying to evaluate the clojure.lang.ArraySeq as a function, when assigning it to two?

Macros produce code, not data. What happens when you write (1 2 3) in Clojure? Just in the REPL or as a line of code on its own. It blows up with the same exception because 1 is not callable.

This is the macro's behaviour then, alright

Of all macros, not just that macro.

Can it possibly be done without aliasing the ns? so 'full.react-ns/View in the macro phase? I think that’s how I’ve done what I think you’re trying to do before

A common way it to emit the CLJS code with FQN: https://code.thheller.com/blog/shadow-cljs/2019/10/12/clojurescript-macros.html#gotcha-1-namespace-aliases-and-dependencies

Thx, @U0VP19K6K. I considered that, but did not know how to translate ["react-native" :as rn] to sth un-aliased. tbh, I am not familiar with that syntax, a string naming the required component. 🤷

Ah, that's an interesting problem then. @U05224H0W Your article above doesn't mention such requires. Do you perhaps have any recommendations?

can you expand into cljs function calls that then call rn/View??

@U0PUGPSFR Ah, that’s a good point! I never did this with npm modules so I’m not sure either I’m afraid.

There may be a format that is not string based…

Great minds think alike! But then my code looks like, say, (mxn/View rn/SafeAreaView etc etc) and when I get to other widgets it would be (mxn/Widget rn/Switch ...). Hmmm, maybe I can go DRY differently. This is for passing to the helix.core/$ macro which does accept strings and keywords for its own magic with "div". I have a question into @U4YGF4NGM in the #helix channel as well.

there is not enough information here. Need to show definition of def-view-macro

there is no problem if the reader reads a symbol rn/View

Wait, strike that, I was hacking at it ^^^

Ok, this is where I started: (defmacro def-view-macro [type rn-type] `(defmacro ~type [mx-props# jsx-props# & children#] `(tiltontec.model.core/make :myapp.mxreact/mxrn.elt :sid (swap! myapp.mxreact/sid-latest inc) :kids (tiltontec.model.core/cFkids ~@children#) :rendering (tiltontec.cell.core/cF (prn :creating ~'rn-type#) (helix.core/$ (mxfnc (apply helix.core/$ rn-type ~jsx-props# {} (doall (map #(tiltontec.model.core/mget % :rendering) (tiltontec.model.core/mget ~'me :kids))))))) ~@(apply concat (into [] mx-props#))))) Usage (def-view-macro View rn/View) fails on "No such namespace: rn"

Not surprised the reader cannot resolve "rn", tbh, since the alias is not defined in this clojure file.

I have tried to go down this route before and run into issues with macro-defining-macros

not saying it can't be done but I gave up, the interaction between the Clojure macro namespace and the CLJS namespace was too complicated and hard to resolve

Yeah, macro-defining-macros are fun. I did OK in mxWeb because I never had to reference a type: I just needed strings to get to the DOM manipulation I was doing. Thx for confirming I am doomed. Copy and paste here I come! :)

Yeah, the only way I could get it to work was to always keep CLJS NSs fully qualified as plain symbols but those were Clojure modules not NPM ones

Probably worth asking on Clojurescript channel though

FWIW if you develop the macros using the recommended companion CLJS namespace then you can put your :require in that and setup whatever symbols you need there

getting the string aliases is also possible but a bit more involved

When using (:require ["react-native" :as rn]) you aren't really getting an alias that is resolving to something called "react-native" you are getting a javascript object, right? Could you pass in a function that returns whatever rn/View is? like a really simple #(.-View rn) And then use that in your macro instead? The idea would be to defer evaluation until it's executed in js land and not in clojure, which seems like what is happening now. I have never attempted to go this far with macros before so no idea if it would work.

Well, @UDVJE9RE3, the Clojure Gods did not suggest that, so... how would my macro generate the .-View? This isn't Lisp, you know. 🙂 Good compromise found, however: https://clojurians.slack.com/archives/CRRJBCX7S/p1629932400134600 It does do what you suggest, reaching out for the rn/View in the expanded code once in CLJS-land. Heading out for 🍾 ....

I'm glad you've found something that works! To answer this > how would my macro generate the `.-View` If you know that you want to use some property called View on a javascript import, then you have a symbol to work with. You can build the .-View symbol in clojure. Consider this macro, dumb example, but for illustration

(defmacro field-extractor [obj field]
  (let [get-field (symbol (str ".-" field))]
   `(~get-field ~obj)))

(:require ["react-select" :as react-select])

(e/field-extractor react-select Creatable) ;; => #object[CreatableSelect]

This might be more like your example

(defmacro lift-js-fn-to-ns [obj field]
  (let [get-field (symbol (str ".-" field))]
    `(defmacro ~field [x#] ;; could easily just be a `defn`
      ((~get-field ~obj) x#))))

(macroexpand-1 '(lift-js-fn-to-ns moment utc))
;; => (clojure.core/defmacro utc [x__280962__auto__] ((.-utc moment) x__280962__auto__))

(lift-js-fn-to-ns moment utc)
;; => #'example/utc

(utc "2020-01-02") ;; => #object[Moment Thu Aug 26 2021 00:39:34 GMT+0000]

Haha, that approach occurred to me but I thought, as I said ^^^, "Ha, this is not Lisp!". And I have played with Clojure symbols but was always disappointed, so I was even less incline to explore that path! I'll give it a try. Thx!

I guess an alternative would be to make all predicate functions that check for isintance in the original code, like is-data-range? , multimethods, and define them as true only for specific classes that were created by defrecord .

is it not feasible to depart from the original design somewhat and just rely on multimethods on ordinary maps? that'd be my first instinct

> somewhat This particular part is not feasible, I'm afraid. The isinstance checks are everywhere.

yow, that's unfortunate. just curious, what's the python lib?

https://bokeh.org/

It heavily relies on classes, hierarchies, metaclasses, property descriptors - few of the many reasons that made me stop using Python. :D But the library itself is great, especially because it has a JS counterpart that just doesn't have alternatives IMO.

> mplement a version of isinstance that would use isa? yes, if you use derive to define the hierarchy, isa? should do exactly what isinstance did, alternatively you can use "marker interfaces" (interfaces with no methods), and implement the apropriate interfaces on each record based on what isinstance should return

of course you can use protocols instead of interfaces, with no methods to define it comes out about the same I think

I have a somewhat cursed impl of python's classes in clojure - if you want to directly translate

Do you have any recommendation, along with the "why"? So far: • Use keyword hierarchy with derive and isa? • Make the predicates into multimethods that dispatch on the class of the record • Create marker interfaces/protocols

@U3JH98J4R I'm somewhat curious but at the same time 80% sure that won't work, unless it's more than somewhat cursed. :D The library heavily relies on metaclasses and property descriptors as well, so I have to adapt, I don't see how I could directly translate that.

(definterface IAnimal)

(definterface ISilent)

(definterface ILarge)

(definterface IHarmless)

(defrecord Panther [color]
  IAnimal
  ISilent
  ILarge)

(let [panther (->Panther "black")]
  {:animal (instance? IAnimal panther)
   :silent (instance? ISilent panther)
   :large (instance? ILarge panther)
   :harmless (instance? IHarmless panther)})

{:animal true, :silent true, :large true, :harmless false}

multiple inheritance you could do. but not much more than that

also have you tried "just" using libpython-clj?

@U2FRKM4TW each of those three can accomplish what you want, I think the question to answer is which of them has lowest friction to translate from python and keep in sync - are the properties that isinstance checks defined when defining the class (marker interface), are they added later from some other procedure? (defmethod)

using derive / hierarchy is probably the most flexible on the clojure side, but least likely to look like the python code

Thanks! Since the code isn't supposed to be that flexible, marker interfaces should do. And now I recall that Clojure itself uses them. @U3JH98J4R Nope, and I definitely won't. I don't like Bokeh's Python API at all. It's immensely overloaded IMO and has a lot of "magic", making it brittle and hard to debug.

yeah, i have a clojure test that should fail (if function args are being tested) since i’m passing an invalid spec which should fail. when using cloverage, the failure doesn’t happen…

hmm, do you recommend doing lein test first and then lein cloverage?

even with

lein with-profile +instrument test :only ...

Ran 1 tests containing 2 assertions.
0 failures, 1 errors.
Tests failed.
Error encountered performing task 'test' with profile(s): 'base,system,user,provided,dev,instrument'
Tests failed.

depending on context yeah - you can make a custom alias using do that executes them in order of that's a common need - like the last one in the sample project.clj

:aliases {"launch" ["run" "-m" "myproject.main"]
            ;; Values from the project map can be spliced into the arguments
            ;; using :project/key keywords.
            "launch-version" ["run" "-m" "myproject.main" :project/version]
            "dumbrepl" ["trampoline" "run" "-m" "clojure.main/main"]
            ;; :pass-through-help ensures `lein my-alias help` is not converted
            ;; into `lein help my-alias`.
            "go" ^:pass-through-help ["run" "-m"]
            ;; For complex aliases, a docstring may be attached. The docstring
            ;; will be printed instead of the expansion when running `lein help`
.
            "deploy!" ^{:doc "Recompile sources, then deploy if tests succeed."}
            ;; Nested vectors are supported for the "do" task
            ["do" "clean" ["test" ":integration"] ["deploy" "clojars"]]}

try lein check - all that does is load up all clj files in source path, and then show any errors / reflection warnings that come up

at least with lein do ... you can execute your separate subtasks without spinning up lein again each time

thanks. also i get the error thingy now, it’s working as expected. cloverage is meant to give you the coverage, and it https://github.com/cloverage/cloverage/issues/296 any test errors to not uglify its output

And does this mean using doseq would process it like a lazy sequence (retaining the head) instead of how transduce or reduce would?

why would doseq ever retain the head of anything?

you could still use transduce to do your IO, just do it in the reducing function, not the transducer

the transducer is there to process your data (data in, data out) and isn't the right place for side effects

...just a nit on terminology, transducers don't process data

transducers transform reducing functions, which process data

right, thanks

and as noisesmith said, IO is absolutely fine in a reducing function

Also, you can't use doseq on an IReduceInit.

So, yes, if you need to process a reducible query, either reduce or transduce are fine, even if your actual reducing function is doing I/O.

(or any other function that will eagerly process an IReduceInit)

Are IReduceInit not seqable?

Ok, I guess not

Seems it be possible to implement first, rest and next using reduce :thinking_face:

#(reduce conj [] %) ?

eagerly consumes, gives you a seqable

I guess that's just into

I think with doseq I was suggesting what @U04V70XH6 said above, the doseq would avoid IReduceInit and instead just eagerly consume the whole result set. But then my thought there was that even though the doseq might be computing a reduction, it would keep all values of the sequence until it exited. This thread has helped a lot. Thank you. The reduction function makes perfect sense. The transducer transforms, and the reducer sends the result to a sink with IO as one option.

I wouldn't expect doseq to ever hold onto a value it is done processing, though if you used the dumb reduce conj I suggested above to get a seqable for doseq it would hold the head

I quess then I wonder if sequence would produce a lazy version of the IReduceInit useful if one were consuming it and say writing a textual representation to a socket or other channel that might be slower.

Sequence will, but it'll still be chunked, so you got to be careful with IO

Now I'm not sure about head retention with it :thinking_face:

You can't call sequence on an IReduceInit either.

Easy way to check in the REPL:

dev=> (def x (reify clojure.lang.IReduceInit (reduce [_ f init] [])))
#'dev/x
dev=> (doseq [y x] (println "Hi!"))
Execution error (IllegalArgumentException) at dev/eval179328 (dev.clj:1).
Don't know how to create ISeq from: dev$reify__179322
dev=> (sequence x)
Execution error (IllegalArgumentException) at dev/eval184697 (dev.clj:1).
Don't know how to create ISeq from: dev$reify__179322

Hum... can you even reduce over it?

I get: > java.lang.ClassCastException: sandbox8122$reify__8761 cannot be cast to clojure.lang.IReduce

Oh, haha, ok you can only if you provide an init value to reduce 😛

Ya, if something is exclusively an IReduceInit and nothing else, seems all you can do is use reduce (or transduce) with passing it an init value.

Just so used to having collections implement so many more things, take it for granted

From the peanut gallery: this was a very informative thread. Thanks all! 🙌

@U0K064KQV Just to show with IReduce:

dev=> (def x (reify clojure.lang.IReduce (reduce [_ f] 0) (reduce [_ f init] 1)))
#'dev/x
dev=> (doseq [y x] (println "Hi!"))                      
Execution error (IllegalArgumentException) at dev/eval184916 (dev.clj:1).
Don't know how to create ISeq from: dev$reify__184910
dev=> (sequence x)                                                             
Execution error (IllegalArgumentException) at dev/eval184920 (dev.clj:1).
Don't know how to create ISeq from: dev$reify__184910
dev=> (reduce + x)
0
dev=> (reduce + 42 x)
1

(but since Rich says IReduce was a mistake, I don't tend to use it)

I looked into that actually, and I found an article about category theory lol. It seems that reduce with an init is a catamorphism, and that makes it it can handle reducing things that don't have a neutral element, or reducing into a different type than the type of the elements. And I guess from a programming standpoint, reduce without an init for those cases would error on an empty collection, and would be possibly unintuitive in the case of collection of length 1

I think the last two might be why Rich thinks it's a mistake.

i always thought this transducer that did IO was kinda clever: https://github.com/Datomic/mbrainz-importer/blob/master/src/cognitect/xform/transducers.clj#L29

For anyone interested, Rich talks about IReduce being a mistake, in his Inside Transducers talk, shortly after https://youtu.be/4KqUvG8HPYo?t=1753, where he says the semantics of reduce was one of the worst things he copied from Common Lisp 😄

Well, actually in @U11BV7MTK’s link to those transducers, it is the transducer that is doing the IO (in the case of ‘.’ printing). This is specifically what has been (believably) pointed out to be a bad idea. Now I do not think this would actually cause a problem. But if one replaces print a dot with doing 1000's of records of IO on a shared resource, it looks like a big problem.

yeah context on this one is important. It is in an example repo, on a command line style problem (migrating data). I think its clever, and its IO is just spitting out to std out.

To wrap up (maybe not, but let’s see) this great thread (thank you all who participated). I over-reach with this, which is mostly intentional, in an effort to flush out any details that didn’t organically surface in the conversation: 1. Doing IO in a transducer is putting a suspendible, memory allocating, and long running operation on a background thread pool designed for the opposite. There is no contractural guarantee to service that IO with care (or even preserve the exceptions for you, I can say with some confidence 😉 ). Therefore do not do IO in transducers. 2. But wait, there is more! The reducer argument to transduce is the same as good old reduce , use it do IO after the transformation. To do IO before the transformation simply use map etc. 3. There is still lots of machinery in sequences and core.async that will happily service IO requests. I find allocating a pool specifically for this is helpful . 4. Libraries for things like Rx (I miss beicon for the JVM) have similar IO pool allocating strategies for operators that will do IO.

Super big thanks @U04V70XH6 for the dive into the interfaces, outstanding! And more thanks for @U0K064KQV for rounding out all the comments and filling in the gaps. I really appreciate the good help.

Also I would add the lore associated with IReduce is very enjoyable. Totally new info (and useful background in understanding the design rationale, not always easy to reverse out of a design).

The one thing that still bugs me a little, is the fact that IReduceInit eats reduced i.e, on early-termination, the implementation is supposed to return the final value, as opposed to the clojure.lang.Reduced wrapper object (Rich talks about this in the same talk). I dunno why IReduceInit was designed this way, as opposed to having the implementations return the wrapper, which would make more information available to callers.

You'd return the reduced to the caller of reduce?

it seems odd to return a reduced, but nothing prevents you from returning (reduced (reduced v))

I believe the way to implement IReduceInit is to respect reduced and terminate early, but when this happens, return the value in the reduced wrapper, and not the wrapper object itself. reduce can remain this way (i.e, not return reduced wrapper) but the interface contract can be to return reduced. As noisesmith pointed out, we can of course double wrap and detect early-termination, perhaps yielding a spin on ensure-reduced that ensures something is reduced twice, or not at all. Doesn't seem as elegant TBH. Something tells me this way is more error prone.

☝️Which would certainly be useful in the case of an actual reduce doing IO, but maybe less so on a transducer that is pure and processing data in a pipeline (and hence “unlikely” to exit early unless it throws).

@U07S8JGF7 this is the thread

@U11BV7MTK thanks!