On Mon, Jan 24, 2011 at 3:22 AM, Eric Schulte <[email protected]> wrote: > Ken Wesson <[email protected]> writes: >> Why (fn [_] value) instead of (constantly value)? OK, actually >> (constantly value) is textually longer, but I'd argue it might be >> clearer. And it works; (constantly foo) accepts all arities. It's >> something like (fn [& _] foo). > > I agree constantly would have been a better choice, had I known it > existed.
Ah. I thought you might have known about it, but not that the function it emitted would accept arities other than zero. >> Whoa. Why not >> >> (defmacro propagator "Define a new propagator." >> [name in-cells out-cells & body] >> `(do >> (defn ~(vary-meta name assoc >> :in-cells in-cells :out-cells out-cells) >> >> ? >> > > Again, I work with the functions I am aware of. Ah. Funnily enough it wasn't long ago that I was "caught" actually reimplementing vary-meta because I didn't know about it. > Thanks for these pointers, they are very helpful especially as it can > be difficult to learn new functions once a sufficient subset has been > discovered. True, that. Though I'd phrase it more as "difficult to discover new functions". When you don't know how to do X or feel it should be a one-liner, if not a single function call, in core, you go trawling through http://clojure.github.com/clojure/clojure.core-api.html or use find-doc and apropos at the REPL to try and find something that fits, or at least simplifies the job. On the other hand when you can slap X together in two seconds flat it may not occur to you to look. The more functions you do know and the more adept you've become at combining them in various ways, the less likely it is that you *won't* think of at least one way to build X quickly, unless X is something particularly big and complicated like a major new piece of GUI functionality or an FTP server or something, and then you're more likely to look for a third-party library (and, probably, a Java rather than a Clojure library at that). I find the cheatsheet at http://clojure.org/cheatsheet useful sometimes for this, if I want to check if core has a function related to a category of use (seqs, say, or atoms) that might be useful. The cheatsheet has a couple of problems. For example, vary-meta isn't in there. ;) In fact there's no section on metadata at all, just a few scattered related things like *print-meta* and the reader macros (which are out of date -- ^ for meta and #^ for with-meta rather than just ^ for with-meta, nothing for meta). Also: * deref/@ is listed under refs, instead of somewhere general or repeated also for atoms and agents. * delay is listed under laziness but force under other/misc instead of with delay * the special forms list is incomplete, missing at least . and set!. The Java interop section lists set! but not . and the vars section doesn't list set!. Nonetheless, keeping those caveats in mind I find it useful. >> What is "add-watcher"? I'm somewhat familiar with add-watch, whose >> syntax would be somewhat different. There'd be nothing between the >> watcher key :send and the (fn ...), and that function would take four >> arguments. > > This was an old project (last spring) and it's version of clojure > (org.clojure/clojure "1.1.0-alpha-SNAPSHOT") is not even resolved any > longer by lein. It appears that the add-watcher function has been > deprecated and replaced by add-watch, which doesn't require that the > function return true allowing the simpler construction you suggest > below. What, it had combined validator and watch functions in one back then? > Interesting point. I think your suggestion would lead to simpler code, > but IMO the existing design is simpler conceptually, I like the divide > of propagators as functions and cells as data, rather than every > function having an associated piece of data (namely its output). That's OK. > I'm not sure which implementation would lead to a more efficient running > system. Having fewer larger propagators which can set the values of > many cells at once, or more smaller propagators each of which only sets > the value for a single cell. It's likely to depend on how many distinct cells (may sometimes not all have the same value) you sometimes need to set to identical values all at once. If you have few such, you don't lose much by having a one-propagator-one-output-cell rule. If you have many such, you probably do. (If you have multiple cells that never have distinct values, they can be replaced by a single cell.) > That would be a great application for this system. Each cell of the > spreadsheet could be a cell, and each formula could be a propagator. > I've implemented this and it seems to work well, I've committed this to > the repo above, and posted the spreadsheet code with example usage into > a gist at https://gist.github.com/792968 Cool. I notice the page at the original URL you posted hasn't been updated though. >> I hope you don't think all of that was too critical. It's very interesting >> work. > > Not at all, I appreciate the code review, your function suggestions and > convention reminders were very useful. > > Many Thanks -- Eric You're welcome. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to [email protected] Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/clojure?hl=en
