Initial stumbling blocks

[kxygk]

Hi,

Sorry I'm getting back to you so late. I appreciate the thoughts you shared with me here:

https://old.reddit.com/r/Clojure/comments/11723ea/is_there_a_reframecljfxlike/

I just tried to convert a little plotting program of mine to use flex and I've hit a few initial stumbling blocks. I only really mean this as to share an initial-impression/user-experience - and not criticism. It's very likely "i'm holding it wrong" and misunderstanding how to use flex.

1. Signals can't be inspected at the REPL
   Just working off the example in the README. You hook up counter-sq to your counter atom. When counter updates, counter-sq updates under the hood. However as far as I can tell, there is no way to actually inspect counter-sq at the REPL. It just returns a :town.lilac.flex/init. You can hook up a listener and print the value, but it's clunky and only prints a single time on change. tbh, I expected it to outwardly continue to behave transparently as a integer - but at the very least I'd want to be able to peak at its value at the REPL :)

2. Not super clear how to chain signals
   I obviously wants to go a step further from the basic example and chain my signals. Leverage diamond dependencies and so on.. Since I can't dereference them, I'm not super sure how to do that? I can listen to a signal and create a new signal - but that seems a bit clunky. I don't think it will do the diamond dependency magic that way as well?

3. signal wrapping everything..
   Basically any variable that derefs a flex/source will in effect be a signal. So I'm envisioning you end up with a ton of this in your code:

(def my-var
    (flex/signal
    ....
...

Maybe just aesthetic but it'd be a bit clearer with a macro

(defs my-var
    ... 

Because you don't exactly have a static variable nor really a defn function. That said, I get the desire to avoid macros :))

4. No quick and easy way to subscribe to map values
   In the CLJFX model the equivalent of signals are split into sub-val and sub-ctx. The latter is a memoized function call - a bit similar to your signal. The former is a convenience function that allows you to subscribe to map values

So as I started to massage my code to use flex, my flex/source atom looked something like this:

(def
  params
  "The state atom"
  (flex/source
    {:input-dir   "./data/gauge/"
     :id-2-name   {1645240 5
                   8373316 3
                   7598252 4
                   1683136 2
                   8371400 1
                   1641660 6
                   7598984 7}
     :inside-d18o  "irregular-cave-samples.csv"
     :outside-d18o "manual-rain-samples.csv"
     :plot-height 400
     :plot-width 1000
     :blah        "blah"}))

From the API it looks like in flex I need to create a signal for each an every key @_@ so that when a part of the map gets updated I get the appropriate update (that can propagate to all the signals). Otherwise my whole DAG gets recomputed on each map update (well I assume it'll terminate when identical values are returned). Ergonomically this is a bit of a mess. Basically if you have a .. simple? (finite/non-lazy) built in datatype as a source, you can be sure you'll automatically want signals for every single elements

in CLJFX sub-val is limited to first level map keys - but ideally then should be able to generate a signal on deeper values

Anyway, those are my first thoughts :))

[lilactown]

Sure, these are great questions. I'll answer them in order

1. Signals can't be inspected at the REPL

Signals can definitely be inspected at the REPL. Here's an example

(def counter (flex/source 0))
(def counter-sq (flex/signal (* @counter @counter)))

;; Our signal hasn't computed anything yet because it's "disconnected"
@counter-sq ;; => :town.lilac.flex/init

;; now it's "connected" and will have a value, and recompute on every change to `counter`
(def fx (flex/effect [] @counter-sq))

@counter-sq ;; => 0

(counter 2)

@counter-sq ;; => 4

(flex/dispose! fx)

;; since `fx` is disposed, it will disconnect the signal, clearing its state and no longer recompute
@counter-sq ;; => :town.lilac.flex/init

You said

It just returns a :town.lilac.flex/init. You can hook up a listener and print the value, but it's clunky and only prints a single time on change

What it sounds like is happening is you're dereferencing a signal that hasn't been "connected." By default, signals do not recompute on change. Only if they are depended on by another connected signal or an effect do they "connect" do they compute their value and react to changes. This allows you to construct as many signals as you want, and only those that are referenced will react to updates and store their value, which is nice for letting letting the GC clean things up so we don't take up too much memory.

Ultimately, the goal of flex is to trigger side effects based on changes to inputs. If you only want to inspect a value, you can do what I did in the example above and create a dummy effect that dereferences the signal. You can then dispose of the effect when you're done. But I'm curious, what do you want to happen as these values change?

2. Not super clear how to chain signals

Since I can't dereference them, I'm not super sure how to do that? I can listen to a signal and create a new signal - but that seems a bit clunky. I don't think it will do the diamond dependency magic that way as well?

I'm not sure what you mean here. "Chain my signals" means you want signals that depend on other signals, right? That is definitely supported. Here's a diamond dependency modified from the tests in test/town/lilac/flex_test.cljc

(def A (f/source 2))
(def B (f/signal (* @A @A)))
(def C (f/signal (+ @A 2)))
(def D (f/signal (* @C @C)))
(def fx (f/effect [] (prn (+ @B @D))))

In this diamond dependency, the propagation algorithm guarantees that each update to A will recalculate each signal only once.

3. signal wrapping everything

You can define your own macro to help you with this. :)

(defmacro defs
  [sym body]
  `(def ~sym (flex/signal ~@body)))

4. No quick and easy way to subscribe to map values

From the API it looks like in flex I need to create a signal for each an every key @_@ so that when a part of the map gets updated I get the appropriate update (that can propagate to all the signals). Otherwise my whole DAG gets recomputed on each map update (well I assume it'll terminate when identical values are returned). Ergonomically this is a bit of a mess. Basically if you have a .. simple? (finite/non-lazy) built in datatype as a source, you can be sure you'll automatically want signals for every single elements

I'm not sure that's a fair assumption, but it's easy to build a helper function for yourself if you like

(defn sub
  [s f]
  (flex/signal (f @s)))

(def params
  "The state atom"
  (flex/source
    {:input-dir   "./data/gauge/"
     :id-2-name   {1645240 5
                   8373316 3
                   7598252 4
                   1683136 2
                   8371400 1
                   1641660 6
                   7598984 7}
     :inside-d18o  "irregular-cave-samples.csv"
     :outside-d18o "manual-rain-samples.csv"
     :plot-height 400
     :plot-width 1000
     :blah        "blah"}))

(sub params :blah) ;; returns a signal that will track the value of `:blah` in the map

[kxygk]

This is fantastic! Thank you for getting back so fast and helping me iron out my misunderstandings

1. Oh it has to be connected!
   Okay! I had missed this point entirely :)) I sort of understand in the abstract the utility of having zero cost "lazy" signals - though I'm a bit hard pressed to think of a case I'd actually really need that (though this is likely just a lack of imagination on my part). Maybe they could be auto-connected by default? In either case, when I print in the REPL it also feels that that would implicitly create a "connection" to the REPL/io. Are you envisioning wanting to inspect a disposed/disconnected value for some reason? Again it doesn't seem like the hot path, and more of a cornercase. So seems maybe a strange default. I actually don't really how you develop interactively - it's possible we just have very different workflows. I like to poke at variable and function all over. Having to rig dummy connections each time would add a lot of friction (but something that could be easily automated with a bit of sugar/function/macros)

2. This was all do to my misunderstanding
   After Q1 this whole part was just me being dumb - but thank you for spelling it out. And I will take a look at the tests as well

3. Thank you for the macro :)) I guess I could add extra things in here. Do you have any suggestions for how to make a hidden equivalent to the the dummy connection you made - but in a way that would not get garbage collected immediately when out of scope? I could see maybe stuffing it into the var meta data... but I'm not super familiar with writing macros or futzing with metadata tbh. Maybe you have better idea for how to create auto-connected signals

4. I don't think this accomplishes the desired effect. The issue is that say for instance you call (sub params :blah) in two different "higher order" signals - each sub call would generate a new distinct signals. Ideally you'd want one signal for each key that is shared across all "consumers" of your atom/source. (again I'm guessing this could be shoved into the var metadata somehow) I guess the final behavior would be identical, but you're just making extra overhead (only an issue if the values/cells are large)

Thank you again for helping me work through the speed bumps. I can definitely start my rewrite with this. I really like your pragmatic/flexible approach.

And please don't take it wrong. I don't mean to come and just say "Your defaults are wrong and you should do things different". I will try to write some macros/helpers for myself as you suggest - I just am a bit apprehensive to make my own ball of mud before i really understand your design rationals. It's likely your way is well thoughtout since you've been thinking about this way longer than me

[lilactown]

And please don't take it wrong. I don't mean to come and just say "Your defaults are wrong and you should do things different".

I would not take your posts this way! I assume that we are both learning. You, about my weird library, and me, about your weird use cases 😛 and each of us about our weird workflows.

I'll respond to a few key points in your last post

Maybe they could be auto-connected by default? In either case, when I print in the REPL it also feels that that would implicitly create a "connection" to the REPL/io.

The downside of auto connecting by default is that you then do not have a way to detect when you should dispose of them and let them be garbage collected.

Take a simple example

(def counter (flex/source 0))
(def counter-sq (flex/signal (* @counter @counter)))

When counter-sq is connected, the counter source needs to hold a reference to it so that when the source updates, it knows to go tell the counter-sq signal to recalculate its value. If we were to redefine counter-sq, that reference would remain lying around, meaning that as you develop over counter-sq signal over time you would accumulate many signals that would all be reacting to counter and never be garbage collected.

You might also end up having a program with 10s or hundreds of signals defined, and (IMO) they shouldn't all be reacting unless they're actually being used to produce some output, otherwise it's a waste. You can also have programs that dynamically create signals in reaction to other signals, which could end up with thousands of signals being created over time, and I want those to be able to be as close 0-cost as possible.

I actually don't really how you develop interactively - it's possible we just have very different workflows. I like to poke at variable and function all over. Having to rig dummy connections each time would add a lot of friction (but something that could be easily automated with a bit of sugar/function/macros)

I think my workflow so far has been to create an app using signals and inspecting them once they're hooked up. So for instance I'll create a web UI that has some sources and signals and inspect them as they change over time. I think that I have tended to do less focused development on a specific signal, as most of my complex logic I put elsewhere.

I see the benefit of being able to test the logic of a signal without it being connected by derefing it outside of the context of a signal or effect. I think one of the things I wanted to communicate to the user is whether a signal in fact is connected or not. Perhaps a better developer experience would be to do something like

@counter-sq ;; => 2
;; prints out "WARNING: Signal dereferenced outside of reactive context"

What do you think?

Do you have any suggestions for how to make a hidden equivalent to the the dummy connection you made - but in a way that would not get garbage collected immediately when out of scope?

I think the risk to creating a dummy connection is actually that it won't be garbage collected once out of scope, because signals and effects keep references to both their dependents and dependencies, so as long as the signal is in scope it will keep the effect in memory. The problem is that if you don't yourself store a reference to the effect, you can't dispose it and disconnect everything.

It sounds like your need isn't necessarily to have a connection that will auto update, but to be able to test the logic of your signals at the REPL. Is that right? If so, I could think about how to create a "non-reactive" branch that will calculate everything but print a warning and not cache its result without a connection, like I suggested above.

Ideally you'd want one signal for each key that is shared across all "consumers" of your atom/source. (again I'm guessing this could be shoved into the var metadata somehow) I guess the final behavior would be identical, but you're just making extra overhead (only an issue if the values/cells are large)

Creating lots of little signals might not be a big deal, but you can also use town.lilac.flex.memo/memoize to create a cached sub function like you're saying.

(require '[town.lilac.flex.memo :as flex.memo])
(def sub
  (flex.memo/memoize
    (fn [s f]
      (flex/signal (f @s))))

(def src (flex/source {:foo "bar" :baz 42}))
(def foo (sub src :foo))

(= foo (sub src :foo)) ;; => true

[lilactown]

Derefing in the REPL

Would you be willing to give the latest in main a try? I implemented the warning to give it a test. Here's the new behavior

(def src (flex/source {:foo "bar" :baz 42}))
(def foo (flex/signal (:foo @src))

@foo ;; => "bar"
;; prints "WARNING: Disconnected signal dereferenced outside of reactive context"

(def fx (flex/effect [] @foo))

@foo ;; => "bar"
;; no warning is printed, because it's connected

In the disconnected case, the body of signal will be recalculate each time it's dereferenced - along with any other signals it might depend on that aren't connected. So it's something that you can do from the REPL to test your logic, but it's not something you would likely do if you're building an app that depends on the value of the signal changing over time - in that case, you would setup a listener or effect.

You can quiet the warning by binding town.lilac.flex.core/*warn-nonreactive-deref* to false

(def src (flex/source {:foo "bar" :baz 42}))
(def foo (flex/signal (:foo @src))

(binding [flex/*warn-nonreactive-deref* false]
  @foo) ;; => "bar"
;; no warning is printed

If you hate the warning, you can manually set the var to always be false once on startup.

(alter-var-root #'flex/*warn-nonreactive-deref* (constantly false))

(def src (flex/source {:foo "bar" :baz 42}))
(def foo (flex/signal (:foo @src))

@foo ;; => "bar"
;; no warning is printed

[kxygk]

Playing around with it right now :)
I'm only seeing a minor issue that the warning are being printed very aggressively - but maybe this is the desired behavior

(def
  params
  "The state atom"
  (flex/source
    {:input-dir   "./data/gauge/"
     :id-2-name   {1645240 5
                   8373316 3
                   7598252 4
                   1683136 2
                   8371400 1
                   1641660 6
                   7598984 7}
     :inside-d18o  "irregular-cave-samples.csv"
     :outside-d18o "manual-rain-samples.csv"
     :plot-height 400
     :plot-width 1000
     :blah        "blah"}))

(def
  sub
  (flex.memo/memoize
    (fn
      [my-signal
       my-func]
      (flex/signal
        (my-func
          @my-signal)))))
#_
(sub
  params
  :input-dir)
;; => #<SyncSignal@7ba1bc5d: 
;;      WARNING: Disconnected signal dereferenced outside of reactive context
;;    "./data/gauge/">

(def
  file-paths
  (flex/signal
    (->>
      @(sub
         params
         :input-dir)
      java.io.File.
      .list
      sort
      (map
        #(str
           @(sub
              params
              :input-dir)
           %)))))
#_
(identity
  @file-paths)
;; => WARNING: Disconnected signal dereferenced outside of reactive context
;;    ("./data/gauge/00rainLog.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/00rainLog2.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/00rainLog3.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/00rainLog4.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/00rainLog5.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/00rainLog6.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/01rainLog-b1.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/01rainLog-b2.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/01rainLog-b3.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/01rainLog-b4.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/01rainLog-b5.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/01rainLog-b6.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/02rainLog-a1.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/02rainLog-a2.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/02rainLog-a3.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/02rainLog-a4.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/02rainLog-a5.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/02rainLog-a6.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/03rainLog-1b.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/03rainLog-2b.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/03rainLog-3b.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/03rainLog-4b.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/03rainLog-5b.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/03rainLog-6b.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/04rainLog-1a.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/04rainLog-2a.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/04rainLog-3a.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/04rainLog-4a.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/04rainLog-5a.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/04rainLog-6a.txt")
#_
(identity
  file-paths)
;; => #<SyncSignal@13f83156: 
;;      WARNING: Disconnected signal dereferenced outside of reactive context
;;    WARNING: Disconnected signal dereferenced outside of reactive context
;;    ("./data/gauge/00rainLog.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/00rainLog2.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/00rainLog3.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/00rainLog4.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/00rainLog5.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/00rainLog6.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/01rainLog-b1.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/01rainLog-b2.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/01rainLog-b3.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/01rainLog-b4.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/01rainLog-b5.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/01rainLog-b6.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/02rainLog-a1.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/02rainLog-a2.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/02rainLog-a3.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/02rainLog-a4.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/02rainLog-a5.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/02rainLog-a6.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/03rainLog-1b.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/03rainLog-2b.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/03rainLog-3b.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/03rainLog-4b.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/03rainLog-5b.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/03rainLog-6b.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/04rainLog-1a.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/04rainLog-2a.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/04rainLog-3a.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/04rainLog-4a.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/04rainLog-5a.txt"WARNING: Disconnected signal dereferenced outside of reactive context
;;     "./data/gauge/04rainLog-6a.txt")>

(sry about my weird coding style)

And thank you for adding the global toggle for the warnings. I'm going to convert my little application to flex and get back to once I have more digested thoughts

[lilactown]

I believe what's happening is (map #(str @(sub params :input-dir) %) creates a lazy sequence of signals that isn't realized until after the signal has been constructed and run, so they are not tracked, which leads to the warning.

This is actually a bug hiding in your code! if you removed the other reference to (sub params :input-dir), your file-paths signal wouldn't be reactive to changes to it. The warning is informing you of this. You can fix it by making the sequence eager, either by changing it to mapv or calling doall on it.

It's possible that flex could call doall for you in this case to avoid this bug. I'll create an issue and think about it.

[kxygk]

Oh woah, you're right! I somehow didn't even think about how lazyness seqs don't really work in an obvious way with signals. That was definitely an oversight on my part. Thanks for catching/explaining it. And yeah, changing it makes just one warning print out :))

[kxygk]

As for doalling the output. I'm honestly not sure. It seems reasonable to me. But to be honest, while I've see all the cool tricks one can do with lazyness, they've always been orthogonal to how I think of code in my head I guess. So I'm probably not the right person to say. It seems one could conceive of a scenario where one would want to defer signal hook up. But I think you can create some pathological scenarios (and glitches)

In CLJFX this is not allowed. When it happens you get a helpful error

https://github.com/cljfx/cljfx

This tracking imposes a restriction on subscription functions: they should not call fx/sub-* after they return (which is possible if they return lazy sequence that calls fx/sub-* during element calculation).

[lilactown]

@kxygk I've migrated this to discussions since I think there might be multiple tasks/issues that come out of our back and forth

[lilactown]

@kxygk making another threaded post because it might be easier to talk about these things without them being intermingled with the deref discussion, but I'm really curious now how you're hooking up cljfx and flex. Could you describe your approach? Do you have any public code you've written so far?

[kxygk]

I have not actually tried hooking up flex to cljfx .. yet!! - but it should be very possible. I dunno if you've really look at the architecture, but vlaaad made it incredible flexible (at the cost of needed some boilerplate to "setup" the framework). There is a subscription model in CLJFX itself, but it's optional and decoupled from the rest of the UI framework. So you wouldn't need to modify cljfx itself. It should be be a matter of tweaking the initialization a bit.

I'm a bit swamped with homework and other research stuff at the moment, but I will come back to cljfx and making a GUI this summer (for a rain pattern extraction program I'm working on) and I'll revisit this then

[kxygk]

So I've been using flex in doing some machine learning homework assignments. It's not be a great fit or stress test for the library tbh :)) - just in terms of problem space. I think flex really comes in to play when you have a large complex problem with a lot of interdependence. In shorter homework style problems simpler/linear scenarios pure functions and transducers are usually enough - but it's still got me thinking a bit

Every simple pure function that takes some static argument, ex: '(my-func arg)' can be refactored to take a signal/state and return a signal. This sort of makes life better..? You can arbitrarily generate new signals, and you can reevaluate by updating the input. More complex functions that maybe calculate some other other properties derived from the input state/signal can sort of do that quietly internally - and if the computation has already been done (memoized) and it can be reused then that occurs automatically

So in the end you can.. In effect turn everything into signals! But in practice.. it's actually kinda tedious and annoying to write :S and it doesn't compose very nicely with idiomatic Clojure. If you want to 'map' over a seq and do some stuff on the items.. Well now what you need is an 'fn' and that's gunna call other 'fn' s and.. It's no longer using all the signals you've been writing.. So to get around this you either have to still write bare 'fn's and then write wrappers that generate signals (but that's also tedious) or maybe create an 'fn' signal before the map call.. and then in the map at every iteration update the input and then deref to get the result?

But the code just seems to get kinda icky everywhere. It's still something I'm exploring and playing around with though

I honestly don' t really have any concrete suggestions at this point yet. I guess at the end of the day what might make life easier is and ergonomic way to be able to write a function that when given a constant returns a constant - and when given a signal returns a signal? Coding with signal you the constant need to deference things everywhere has weird knockon effect - as you can't really use the signal blindly as a value. But this is a just a bit of a half baked thought at this point :))

Anyway, those are my first kind of disjoint thoughts. And I also just want you to know I'm still trying flex out and looking forward to figuring out how to integrate it into my workflow