On Friday, October 17, 2014 11:22:22 AM UTC-4, Phillip Lord wrote: > > > James Reeves <ja...@booleanknot.com <javascript:>> writes: > >> > >> Actually, I think that this is a real problem with Clojure, and with > >> data access. It is very hard to change between accessing a var as a > >> value and through calling a value. > >> > > > > Curiously, this is something I don't think I've ever run into. > > > > Perhaps I'm the outlier, but both the examples you give seem a little > odd > > to me. > > I don't know who is the outlier. The point is that Scala, for instance, > has explicit support to hide the distinction between accessing a value > and computing a value. The point is to support the uniform access > principle. > > http://en.wikipedia.org/wiki/Uniform_access_principle > > To my knowledge, Clojure cannot do this. >
It seems to me that some support could be created for this. Specifically, we'd want to make it that a) (deref foo) on a non-IDeref just evaluates to foo in a no-op, and furthermore that if foo is known at compile time not to be an IDeref the (deref foo) compiles away to just foo, so has no runtime cost; and b) (deref (delay (some-fcall))) amounts to (force (delay (some-fcall))) and where the compiler knows the thing being derefed is a delay (via type hint or whatever) is as efficient as just (some-fcall) at run-time the first time called, and as efficient as ((constantly foo)) for some value of foo thereafter. In that case, one could hide the computed-or-not nature of some data behind expecting users to use @my-thing to access it, and if my-thing is not an IDeref it is the same as my-thing, but it can be changed later to a delay to make it a lazily-computed thing without breaking the API, and without much runtime efficiency cost, given that the new object is hinted with ^IDeref or something. -- 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. For more options, visit https://groups.google.com/d/optout.
