Hey Craig and 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


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
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
For more options, visit this group at
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 6 of 10 | next ›
Discussion Overview
groupclojure @
postedNov 26, '13 at 4:42a
activeNov 28, '13 at 4:57a



site design / logo © 2022 Grokbase