FAQ
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+unsubscribe@googlegroups.com <javascript:_e({}, 'cvml',
'clojure%2bunsubscribe@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+unsubscribe@googlegroups.com <javascript:_e({}, 'cvml',
'clojure%2Bunsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 7 of 10 | next ›
Discussion Overview
groupclojure @
categoriesclojure
postedNov 26, '13 at 4:42a
activeNov 28, '13 at 4:57a
posts10
users5
websiteclojure.org
irc#clojure

People

Translate

site design / logo © 2022 Grokbase