Closed micha closed 10 years ago
Will look at the impl in detail later, but two questions:
= (…)
args, rather than advertising input
and restricting cell
to formulas? I actually misread the formula cell examples as providing some kind of sugared, single-argument =(…)
syntax, before snapping to and realizing that that's not possible. The "formula cells take two arguments" doc confuses even further, as long as the examples (and typical usage) presents the =
and following list as (visually) a single token.IWatchable
s. I do this now in a couple of circumstances to add purely side-effecty stuff that I don't want to risk exposing to the macro magic, and I suspect I'll need it at some point to be able to detach dynamically-created cells for GC purposes (at the moment, I'm successfully not caring, but that could change).Thanks for continuing to develop the lib! :-)
OK, so:
(cell =(...))
form because it mirrors the way you'd create formulas in Excel. Maybe this is foolish?done!
function which would detach a cell from the propagation graph, facilitating GC. We never used it and have not yet found a situation where static allocation didn't work for us. It was removed in c934a2d859114ece2c58255359ad452105e5b343.IWatchable
support on formula cells conflicts with the mechanism for throwing exceptions when an attempt is made to swap!
or reset!
a formula cell. This is something that has bitten me a few times. Is the tradeoff worthwhile?IWatchable
on formula cells (it still works on input cells). For example:;; the IWatchable way
(add-watch my-cell ::key (fn [_ _ _ _] (perform-side-effect)))
;; the Cell way
(cell =((fn [_] (perform-side-effect)) my-cell))
;; note that the cell macro doesn't walk anonymous fns
;; you can get a cell's previous value by (.-prev my-cell)
No, I think the connection with =
is good, I'm just chafing at the overloading of cell
, since inputs and formulas here have completely disjoint functionality / semantics (unless you're contemplating tackling possibly-recurrent, propagator-style networks, but I assume not?), and reusing it for inputs and formulas forces the dummy =
symbol notation. Maybe cell
and cell=
would be simpler all around? Hopefully I'm doing more than bikeshedding here.
The majority of my usage is necessarily dynamic (we can skype sometime if you want details, or maybe @alandipert can fill you in if he remembers what I blathered about in STL), and what feels like a large amount of it to boot. (Up to ~3000 cells allocated over and over based on user interaction, each set hooked up to the [relatively very small] UI that is statically allocated.) Like I said, maybe IANGI, but GC is something lingering in the back of my mind. I can always file an issue / hack around if/when it comes up. :-)
I sometimes avoid putting side-effecty stuff in cells because the code walking doesn't play nicely with some forms; I remember having issues with for
, doseq
, and try
at various times in the past. Maybe whatever was causing that has been fixed since; sorry, I should have created issues with some examples for each.
I don't care much where the syntax lands, but will admit (cell =(...))
looks cool. I also like the general idea of separating input/formula semantics syntactically, and think the current situation with quote
is less than awesome.
All things considered I'm with Chas on cell
and cell=
being the provided API. IMO (cell =(...))
is too magical in that (cell =x)
looks like it might work, but wouldn't - at least not without additional, complicating sorcery.
Re: add-watch
vs. 'the cell way' for side-effecting leaves, the one asymmetry I see is the ability to remove-watch
on IWatchables
vs. the current inability to remove attached cells. As I think usage of both remove-watch
and cell detachment are probably bad things to be doing without precise motivating perf/GC reasons, I don't see the need to add either, yet.
OK, I like cell=
, too. So maybe that part is settled. I will make modifications and we can see how it feels.
@cemerick Wrapping your doseq
or for
expression in an anonymous fn
will protect it from the cell=
macro. Anonymous functions are opaque to the cell=
macro—it doesn't descend into them or code-walk their bodies. So you could do this, for example:
;; macro gets confused with this
(cell= (doseq [x my-cell] (perform-side-effect x)))
;; macro doesn't descend into fn here, so doseq is protected
(cell= (#(doseq [x %] (perform-side-effect x)) my-cell))
See CHANGES.md in the optimo branch and the updated README.md
Please let me know what you guys think before this is merged...