Before you decide on the question of macros/dsl versus data api, I would recommend watching the "(not= DSL macro)" talk from a few years ago. It nicely illustrates the tradeoffs involved, and hints at the reasons why the Clojure community, as opposed to traditional lisps, tends to gravitate more towards data-based than macro-based.
The "one ring to bind them all" talk was also quite enlightening in this regard. (Please do not misunderstand me: I am not advising against a DSL, I just want to help you choose knowingly.) On Tuesday, 26 November 2013, Kevin Bell wrote: > Hey Craig and Jeroen, > > Jeroen: > > Can you elaborate on what kind of features you would like to support? Are > you just deciding on DSL syntax or do you have already some kind of Clojure > layer working? > > -My main goals are to create as "pretty" of a format for defining CF > templates within Clojure syntax and support compiling/decompiling to/from > JSON templates. I would definitely like to do some amount of validation, > taking advantage of the > schema<http://vstoolkit.amazonwebservices.com/CloudFormationSchema/CloudFormationV1.schema> > and > perhaps some of the logic from the eclipse > plugin<https://github.com/aws/aws-toolkit-eclipse/blob/master/com.amazonaws.eclipse.cloudformation/src/com/amazonaws/eclipse/cloudformation/templates/schema/TemplateSchemaRules.java>, > though I'm not sure yet how rigorous the validation should be. > > -I think some really nice additional features would be some kind of > launcher, perhaps done as a leiningen plugin and using amazonica, and > simplified creation of custom CF resources, which are incredibly powerful > and I think fit well with the principles of Clojure, as they are meant to > be small, idempotent modules of functionality that follow a certain protocol > > About the DSL, in the end I decided to stick closer to the CF syntax to > avoid confusion and documentation mismatches. So for instance, all my > parameters for a CF resource are CamelCase. One of the most important > features for me is the validation on missing fields and Reference checking. > > -I was thinking about this too and started with camel case, but I've been > using AngularJS a lot lately, and I actually love the fact that it converts > to/from hyphen-case and CamelCase as convention dictates, so I think I want > to implement that. It shouldn't be too hard to do using some autocorrection > of case based on the schema (above) > > If you are interested in collaborating in this, please let me know. > -I'd love too. Please feel free to contact me at kevin.a.bell (at) gmail > > Craig: > > Typical advice is to not use macros (implicitly used in the gists to build > a CF DSL) when functions or data will suffice. Sometimes however the > syntactic sugar is quite tasty and hard to overlook. I do not have enough > knowledge of the domain to suggest what might be the correct approach in > this case. > -That makes sense, and I was thinking about using functions for things > like the mappings, resources, etc. However, it seems nice to have variables > that can be reused later in the template. Keywords could work for this, but > I feel like that gets a bit awkward if you look at what I was trying to do > in the keyword-heavy version. One thing that struck me about the version > using macro-defined variables though is that, since the whole template > syntax ultimately just produces a big map, defining/using variables within > it is equivalent to doing (def mymap {:first-key (def mystring "a") > :second-key mystring}), which works, but is that weird? > > Some additional comments: > - your use of with-foo pattern is not idiomatic afaics; this pattern is > typically used to scope run-time resource usage > -This is something I've been struggling with a bit. The thing is that > while CF templates are just JSON files, they actually have an explicit > execution path and various scope considerations at runtime. So on the one > hand, this is just a tool to produce JSON data, but on the other hand there > would be a real meaning to the scoping implied by the with-foo syntax > > - in relation to parameters: the means by which defrecord introduces > record attributes may be instructive (if you go the DSL route) > -I like that idea of having the parameters simply being defined in square > brackets "[]" at the top as in defrecord. However, each parameter does > require a potentially large map of properties (type and validation > information), which may be hard to fit into that syntax > > Thanks a lot for the feedback so far! > > -- > -- > 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<javascript:_e({}, 'cvml', > '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 <javascript:_e({}, 'cvml', > 'clojure%2bunsubscr...@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 <javascript:_e({}, 'cvml', > 'clojure%2bunsubscr...@googlegroups.com');>. > For more options, visit https://groups.google.com/groups/opt_out. > -- -- 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.
