Stop using metadata notation

[cemerick]

Hey @lynaghk (and whoever else). Following up on the spike of using sjacket (see the corresponding branch), a thought I'd like feedback on:

Since the Clojure reader isn't being used anymore, the e.g. ^:clj tags don't actually denote metadata. It seems that cljx should stop using them, and perhaps adopt feature expression-style (née Common Lisp-style) tags e.g. #+clj. sjacket currently parses these (properly) as reader literals, so matching and eliding/transforming their value portion is no more difficult than the ^:clj-style tags.

Along with an option to define the "features" that are to be turned on on a per-build basis, this would make cljx a fairly general-purpose s-expression preprocessor.

Thoughts?

[lynaghk]

Is there an advantage of the feature-expression syntax you proposed vs. metadata beyond the semantic cleanliness?
(Which itself is not obvious to me---isn't a form's expected runtime metadata about that form?)
Couldn't we do per-build features with metadata as well?

[cemerick]

My basic thought is that different things should look different. When you're using cljx, ^:clj and ^:cljs are not metadata, even though they look like it. Maybe an argument can be made that they are metadata, just not of the runtime variety, but I think it's worth not getting into such subtleties.

Yeah, we can do extensible per-build "features" with metadata, but we (and any user, perhaps unwittingly) will just end up impinging upon that "namespace" even more. i.e. even more metadata is subject to conditional elision, e.g. ^:jvm, ^:debug, ^:only-for-customer-A, etc.

[lynaghk]

I think that's a reasonable argument for switching to feature expressions.

How far do you want to take them?
Annotating forms with structured data and doing queries to determine what to include/exclude?

[cemerick]

Definitely wasn't planning on going that far, at least not to start. I'm not sure many people actually want to "query" their code (various other higher-order projects aside); just the equivalent of a pile of defines (a set of enabled "features" per build), and I suppose an optional seq of transformation fns, (as it is now) so we can continue to provide sane defaults for cljs around comment, defmacro, etc.

In the end, the practical user experience won't change much at all, i.e. I'm guessing there's ~3 people that ever wrote new kibit rules for use with cljx. Two curated presets (one for each target) + a knob to add additional features / degrees of freedom should do it.

[lynaghk]

I say go for it, then.

[cemerick]

Done. :-)