Hi Ryan, thanks for your interest - and for remaining open, because things will get weird here for a moment :-)
I didn't mean to say that macros are a substitute for data manipulation; they are just a related thing, of arguable utility depending on context, that come along with the idea of Lisp. In general, I too prefer function composition. The problem hlisp addresses is that out of the box, the DOM doesn't come with anything like function composition at all. Many people resort to something worse than even 'data' as we know it to deal with this issue - they write big DOM programs with C-preprocessors they call template engines! Something better than this is to represent DOM in the hiccup style and perform higher level data manipulation using a programming language. I see the relationship between string-munging template languages and Clojure-style data manipulation of hiccup as roughly the relationship between C-preprocessor macros and Lisp macros. Data driven is clearly better, and most of us in Clojure-land are already here when it comes to representing and emitting DOM or DOM fragments. Conspicuously missing from this continuum is the thing we really want: functional composition. This is the flavor of composition we use most when we're programming. How do we get it? Well, in order for data to compose with other like data in the way we're used to functions doing, we must apply 'denotational semantics'. Lisp's semantics are things like: a list means a function call. The first thing in the list is the function. The rest of the things are arguments. If we provide a set of "primitive" operations - "the 7 things" [1] - and then apply the combination of our primitives and our semantics to Lisp data - we have a programming language, Lisp. Once we have Lisp, we have a way to perform functional composition and do all the other great stuff one can do in Lisp. As a programming language now, our data has sprouted the ability to compose with other like data in possibly novel ways without us necessarily adding more base semantics to our interpreter. In a sense, our data has become infinitely meaningful, because it is now Turing complete. This is what hlisp is: it's a means to a real Lisp, ClojureScript, atop not traditional lists, but DOM elements. Where Lisp is that thing that happens when you apply the 7 things and semantics to lists, hlisp is the thing that happens when you apply the set of primitives and semantics Micha Niskin designed [2] to the DOM. The result, in my opinion, is mindblowingly beautiful and extremely powerful. By making the DOM a Lisp - and not just any Lisp, ClojureScript - we have a means to *real* DOM component modularity. The exact same modularity that you get with things like namespaces and closures. Where various other HTML component systems drag in their own reference types and scoping rules and evaluation semantics, we have just ClojureScript's usual rules. That's because, via the IFn protocol, it's possible for us to make DOM elements invokable. As implementers of IFn, hlisp-generated DOM nodes can participate fully in the ClojureScript world without introducing new scoping constructs or DOM-specific composition rules. As a result of all this, we have no need to represent HTML anywhere as data. Everything is a program, and expressions in this program may evaluate to DOM. There are no templates, just expressions. I encourage you to check out our "Getting Started" page to see just how powerful functional composition can be when applied over Lispified DOM nodes. It's worth noting that hlisp is not an interpreter - it actually compiles HTML to ClojureScript. As a result, our entire program including 'markup' can now benefit from Google Closure stuff like optimization and dead-code analysis. My reference to macros in my previous post was just this point: you can write macros in Clojure to write hlisp the same way you can write macros in Clojure to write ClojureScript. Again, this is something that just falls out of Lisp and doesn't necessarily have much to do with hiccup or the idea of the DOM as data. I hope this cleared things up for you. Don't hesitate to join us on our mailing list or in IRC #hoplon if you have further questions! Happy Lisping, Alan 1. http://www.paulgraham.com/rootsoflisp.html 2. https://github.com/tailrecursion/hlisp-starter/blob/master/PROJECT.md#html-is-semantically-compatible-with-lisp On Friday, December 20, 2013 2:01:37 PM UTC-5, Ryan Spangler wrote: > > The hlisp part of Hoplon - the compiler bit that converts HTML to >>> ClojureScript - was designed and implemented specifically to avoid having >>> to do this. It's our opinion (and experience) that admission of the DOM as >>> a data structure instead of a piece of the program introduces tremendous >>> complexity. This data structure must be explicitly interpreted, evaluated, >>> and updated in complicated ways that tend to couple tightly to both overall >>> state logic and DOM quirks. That said, Hoplon markup can be manipulated as >>> data the way any other Lisp program sanely can - via hygienic macros. >>> >> > I am curious about this. I have had the opposite experience. Whenever I > use a library based on macros I find myself wanting to do something with > them the macro writer did not expect, and being forced to wrap the macros > in functions so I can compose things programmatically (which seems to me > like unnecessary complexity). I can't pass macros around as arguments, > store them in a list, or apply them to arguments in a general way. > > On the other hand, if I am just working with a data structure, I can write > functions to manipulate the data in novel ways and even use many functions > that already exist to manipulate data without having to recreate that > functionality for a specific domain (like looping, merging, search and > replace etc). > > So I am curious specifically what flexibility you are gaining by using > macros (things you can't do with functions and data) that would offset the > flexibility you sacrifice with macros? I am open to being convinced on > this point! > -- -- 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/groups/opt_out.
