With fexpr you could consume data structures passed from backend to fronded but in evaluation manner basing on specification/declaration without need for doing interpreter design pattern. The question you raised could be also applied for example to multimethods. Multimethods could be achieved by writing dispatching mechanism on your own, however for better brevity it was implemented in the language.
On Monday, 23 May 2016 09:51:40 UTC+2, Val Waeselynck wrote: > On Friday, 6 May 2016 12:10:38 UTC+2, Olek wrote: > > Hi! > > > > Because macros are evaluated at compile time (they are compiletime > > metaprogramming) and can't be used in eval in ClojureScript we need the > > Fexpr https://en.wikipedia.org/wiki/Fexpr to be able adapt new flow > > concepts. For example it would be handy to write interpreter pattern just > > by calling eval on data structures of clojure to buildfor example UI based > > on mo-boostrap clojurescript library. > > > > Maybe there is already lib for Clojure/Clojurescript which will allow to > > gain such functionality like Fexpr. For me the easiest solution is to > > override let to be able to specify delay objects which can be later > > consumed with deref/force. Of course the let should be expressive and > > succinct enough to be used seamless, for example: > > > > (defn my-if [ condition ~lazy-on-success ~& optional-lazy-on-failure ] > > (if condition @lazy-on-failure ~@optional-lazy-on-failure )) > > > > and the use could be: > > > > (my-if (:some-condition some-request) > > (do (println "do-some-side-effect") (println "and here another one")) > > (println "the failure side effect")) > > > > (my-if (:some-condition-2 some-request) > > (println "only on suscess")) > > > > This is actually the only thing which I miss for succinct coding though all > > layers of JEE apps. Runtime (and reflective) metaprogramming is right now > > nicely supported by Groovy and JRuby, why not to bring it to ClojureScript? > > It's not clear to me what such runtime metaprogramming features would bring > to the table? > > Seems to me that having first-class functions, and multimethods and protocols > defined at runtime is quite enough, I'm not sure what we're missing here. I > get that Groovy's runtime metaprogramming features can be useful, but they're > addressing the issue that classes and methods are so desperately not dynamic. > > Generally speaking, I believe one of the guidelines of Clojure's development > has been not to add features unless their utility is proven - 'why not add > <x>' is not going to be enough :). Coming from the Scala and Javascript > worlds where the proliferation of features leads to tons of distractions and > incompatible interfaces, I'm personally quite happy with this phiosophy :) > > > > > Thanks in advance, > > Olek -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/clojurescript.
