This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # asami (1)
- # babashka (4)
- # calva (22)
- # clerk (2)
- # clj-kondo (32)
- # cljdoc (2)
- # clojure (49)
- # clojure-europe (9)
- # clojure-norway (3)
- # clojurescript (4)
- # data-science (5)
- # datascript (8)
- # datomic (7)
- # events (1)
- # fulcro (3)
- # hyperfiddle (62)
- # malli (4)
- # missionary (3)
- # off-topic (41)
- # polylith (11)
- # re-frame (19)
- # remote-jobs (2)
- # sci (7)
- # sql (51)
- # tools-build (2)
- # yamlscript (38)
Interesting. I just started reading a book about common lisp today. I'll keep that in mind
a good intro to reader macros in lisp is https://gist.github.com/chaitanyagupta/9324402
From that link I got to http://www.paulgraham.com/onlisptext.html which has a downloadable PDF of On Lisp 🙂
The kinds of macros you're talking about are a bit different than reader macros in that (to my understanding) reader macros operate at the character level. But, they'd similar in that they'd operate at the syntax level not semantically as normal macros do. Maybe one way of thinking about it would be--reader macros extend the reader and normal macros extend the compiler or evaluator.
I think YS macros will be reader macros by definition because YS itself is just a reader of an alternate syntax for Clojure, one that tries to make use of the best parts of YAML in the context of a Lisp.
All of the code for YS translation takes place in a module called
YAMLScript::Reader for the Perl implementation (over Lingy) and
yamlscript.reader for the new Clojure implementation being worked on.
The Perl YS is more of a real reader because it's output is a Lingy AST, where for now the Clojure implementation will "cheat" and just transform YS to Clojure.
I am familiar with Clojure reader macros from Lingy. Regexes and lambdas are reader macros, yes?
Yes, with Clojure the reader is extensible through dispatch macros, but they don't have full access to the reader the way reader macros do in Common Lisp.
It keeps things simple while still allowing you to extend the reader https://clojure.org/reference/reader#_dispatch
I've read that Clojure doesn't provide ways for people to make their own reader macros, iirc to keep Clojure variants from abounding. YS will promote making your own (reader) macros, but I think that's ok because YS is already restricted to needing to be valid YAML, and it's the clumsiness of writing code as ASTs in YAML that these macros help alleviate.
You can write you're own dispatch reader macros, but as I mentioned they're more limited that full reader macros in Common Lisp.
Playing around a bit... This YS:
has ys macro syntax for
a =: 123 b =: if (a > 100): - "big" - "small"
ifthat reads the same as this clojure:
and they could be defined in YS with something like:
(def a 123) (def b (if (> a 100) "big" "small"))
defsyn def: key: ( sym sp+ "=" ) clj: ( 'def (first key) val) defsyn if: key: ( "if" sp+ ysexpr ) val: - seq: 1 clj: ( 'if (third key) (first val) ) - seq: 2 clj: ( 'if (third key) (first val) (second val) )
The processing steps are something like: • if we are a mapping pair • match the key against the list of patterns like • string "if" + 1 or more spaces + an expression • if the key matches • generate clojure based on the relevant parts of the key and the value
without the ys macros you can still do:
in basic ys, the macros just offer other styles to write things in
def: - a - 123 def - b - if: - (a > 100) - "big" - "small"
There's currently about a dozen of these special cases, but I realized that libraries will want their own, and then programmers will want their own as well
It occurs to me that this
defsyn syntax is itself a special macro syntax and should probably be first thought out in its explicit functions.
It's important (I think) to keep in mind that YAMLScript's goal is not to save Clojure from Lisp. It's to introduce Clojure to YAML and to make YAML programmable. Those goals can be easily fairly easily accomplished but if the result looks like a turd, nobody will be interested.
Dylan and Elixir both are languages that behind the scenes are Lisp, but have a more conventional syntax on-top.
The folks behind Dylan even wrote a paper about it, they call them d-expressions, in a similar vein as s-expressions
And Elixir's syntax was evidently inspired by the idea that John McCarthy originally had for what he called m-expressions that would be translated into the underlying s-expressions.
Dylan's also a language that was evidently influential on Clojure, so it'd be interesting to see some of that come full circle.
@U118UP8HH https://people.csail.mit.edu/jrb/Projects/dexprs.pdf looks interesting. I've added it to my reading list.
Have you read about yes-expressions? https://metacpan.org/dist/YAMLScript/view/lib/YAMLScript.pod#ysexprs-%22Yes-Expressions%22