The key thing to remember with embedded DSLs in Clojure is that you are always beholden to the constraints of the Clojure reader. By design, Clojure does not allow you to extend the basic syntax in a way that others can't read without reader modification. Note that you are not constrained by evaluation (as macros get read but unevaluated data).

So making a DSL usually means creating a mapping from Clojure data types into your domain

https://github.com/noprompt/garden is a popular Clojure lib for CSS if you want to see an example in this domain

It's reasonable as completely as disappointing. Btw garden and it's selectors as keywords thing are exactly what I want to avoid 🙂 It's completely unnatural. (On the other hand the hiccup is nearly perfect and even better than html. It's just doesn't work in this way with css.) Will investigate limitations of reading css by macro. Thank you for quick and comprehensive response!

You can read a bit more about the rationale in the history of Clojure that Rich Hickey wrote for the History of Programming Languages conference: > One thing conspicuously missing from Clojure are Common Lisp’s reader macros. While they fully empower the user to create a language of their own specification, such languages are islands. Critically, they require the presence of specific code to read particular data, such requirement being in direct conflict with some of the benefits of independent read/print enumerated above. I saw reader macros in the CL style as being in direct conflict with library development, interoperability, Clojure data (edn) as a wire format etc. I am certain that had Clojure had reader macros, and users availed themselves of them, the large, composable, data-driven library ecosystem that arose around Clojure would have been compromised or thwarted. > https://download.clojure.org/papers/clojure-hopl-iv-final.pdf

One particular macro library that may be of interest to you is infix, which uses macros to do standard infix-style math expressions: https://github.com/rm-hull/infix

https://aphyr.com/posts/353-rewriting-the-technical-interview

Completely understand the rationale, but it's debatable. Such thing as reader macros is essential feature when it needed and it's just missing. And speaking about islands. For me https://github.com/noprompt/garden looks exactly like the island. Isn't it? So much efforts and time to reinvent the notation which already exists and well serves. Sometime it's cool to incorporate existing stuff when it is good enough instead of reinventing or wasting life to overcoming artificial limitation.

Shen lang has such thing as compiler-compiler https://shenlanguage.org/OSM/Recognisor.html

You can debate it all you want on comp.lang.lisp or lambda the ultimate, but it's not up for debate in Clojure itself. I don't think it's "missing" if it's been excluded for a specific reason. I use Garden pretty frequently. Being able to use all my familiar sequential and map-based fns on CSS rules doesn't seem like an island to me when compared with a new syntax to learn.

I don't want to debate it at all but thanks for advice 🙂

Instaparse uses a different grammar in clj/cljs files, but you put it in a string (as far as Clojure is concerned). Since Clojure has always had multi-line strings, it's no bother. Of course there's no syntax coloring, but that's not Clojure's fault - rather it would be an enhancement to the IDE.

I think “unnatural” is a funny descriptor here …

what feels natural is very different from one person to another

for myself, despite missing Common Lisp reader macros occasionally, I have come to like the “everything is data and can be operated on in the same way” approach that Clojure takes. that said, there are certainly use cases for truly getting out of Clojure syntax (e.g., you want to have an artifact that a designer or frontend developer who has never heard of an s-expression can work on). In those cases I have found it simplest to just move that CSS or whatever other thing into its own file, and parse it from Clojure. That also gets you those editor affordances (syntax highlighting, indentation) that phill mentioned too.

"unnatural" in my message has quite specific meaning: transferred to clojure css is much more complicated than css itself. It even doesn't serve any purpose, just to overcome absence of grammar extensions (as far as i see the garden even has become full featured preprocessor in the end). Just another complicated thing to learn and constantly to figure out how to express whats needed and how it would be translated to target language then.

I agree that in most cases it good enough just use clojure data structures to model domain. But not in this particular case - css. And anyway, modeling with grammars is superior technique than any other. But what are you doing guys is rationalizing why no one actually needs this. Let's everyone will stay on their own

Rich showed somewhere how ridiculously modeled http with OOP when it actually was just mappings in the first place and asked "what happend?". That what I feel by looking at clojurish css.

There are definitely times when it would be useful to create and embed your own syntax. That capability has tradeoffs - it adds substantial complexity to the reader, and creates the possibility that you may have Clojure code that is impossible to read (Clojure read, not human read) without the appropriate reader macros. Rich weighed these and decided the costs were greater than the benefits.

There are langs that embrace this idea (Racket most obviously). Clojure is not one of them.

@U44T5FWA3 When I started Clojure I did extend the reader and have never used it ever since. https://github.com/henrik42/extended-lisp-reader

It should be noted, for completeness, that Perl allows embedded any-syntax-you-want and the less said about it, the better.