Spyscope has some similar reader macros. One of my favorites, obviously for the REPL and not for production code, is quite simple -- {eva/l clojure.core/eval} -- I use it to evaluate forms in the scope of the REPL prior to passing them onto threads that don't share the REPL interns.
When you get to be smart writing a macro
21–28 of 28 posts
Re: When you get to be smart writing a macro
#22Macros were the OG prompt engineering.
Re: When you get to be smart writing a macro
#23Earlier quoted context omitted.
I think what's more important than the character count is the fact that you can add #p with two key strokes. Inserting parentheses requires moving your cursor around or invoking some shortcut in your editor if you use paredit, vim-surround, or a similar plugin. Applies equally for removing the invocation (although paredit makes that part easy).
paredit, parinfer and whatever other Clojure/lisp editing tools exist make this trivial though. Editor macros also exist to wrap expressions in calls.
Good point. The parinfer implementation just perhaps needs some kind of nudge to know that when (p is added in front of an object, the parenthesis goes after just one object. If it creates the matching parenthesis in the wrong place (like end-of-line), then you have to manually mess with parentheses.
Re: When you get to be smart writing a macro
#24#p x is one character less than (p x) When code golfing Lisps you can remove all whitespace after a closing paren, but not after a symbol. So in the following fully golfed token sequences, #p loses its one character advantage: #p x y (p x)y I bring up code golfing because that's what this is about, presumably. But what if the argument is a parenthesized expression: #p(x) (p(x)) #p is back in the game with a 1 char le…
I think what's more important than the character count is the fact that you can add #p with two key strokes. Inserting parentheses requires moving your cursor around or invoking some shortcut in your editor if you use paredit, vim-surround, or a similar plugin. Applies equally for removing the invocation (although paredit makes that part easy).
[deleted]
Re: When you get to be smart writing a macro
#25thank goodness for firefox reader mode
Re: When you get to be smart writing a macro
#26Earlier quoted context omitted.
Isn't this the exact same number of keystrokes? 'Shift-3 p' versus 'Shift-9 p' on my keyboard.
I think GP is saying you don't need to define where a closing 'Shift-3 p' goes, not that the initial character is a single key. A Lisp dialect is probably a poor choice if that's one's concern though.
The closing parenthesis is auto inserted, so also the same?
Re: When you get to be smart writing a macro
#27I started using Clojure in 2009 and used it heavily for a long time. I even ran my local Clojure meetup for many years. Lately, I've moved away from Clojure however and today I mostly write Typescript, some hobby C++, some Rust. Gleam when I can (which is rare). Anyway, that's just context to say that I've written and enjoyed a lot of Clojure which made me think about macros a lot over the years. I've come to the con…
> macros cannot see into functions, so core.async requires its async functions to be called directly within a go block (eg you cannot wrap core.async/ Is that something specific to Clojure macros? How does that macro discovery process work, so that they cannot be called inside a helper function? I might not understand exactly what you mean. This sounds very limiting.
No, it's a theme in syntax.
For instance, you can't put the "break" of a "for" loop in a helper function called out of the for loop. It has to be enclosed in the for loop.
We can think of the loop as a macro; Lisp would implement it as such.
When macros transform certain expressions enclosed in the macro call, all the syntax has to be right there, enclosed in the call.
In other words macros are "local syntactic transformations". Why I'm putting that in quotes is that this is the exact phrase used in the paper "Macros that Reach Out and Touch Somewhere" by George Kiczales et al.
Kiczales describes a macro system which peforms global program transformations, allowing macros to act on code that is not enclosed in them; i.e. bring about nonlocal transformations.
"In this paper, we present a new kind of macro, called a data path macro, in which transformations can take place at any point along the dataflow path that includes the macro invocation."
This is pretty exotic. I think nbody has done anything like it, and they never released their code. They left unsolved problems documented in section 5, Future Work.
Re: When you get to be smart writing a macro
#28Earlier quoted context omitted.
> macros cannot see into functions, so core.async requires its async functions to be called directly within a go block (eg you cannot wrap core.async/ Is that something specific to Clojure macros? How does that macro discovery process work, so that they cannot be called inside a helper function? I might not understand exactly what you mean. This sounds very limiting.
No, it's a theme in syntax. For instance, you can't put the "break" of a "for" loop in a helper function called out of the for loop. It has to be enclosed in the for loop. We can think of the loop as a macro; Lisp would implement it as such. When macros transform certain expressions enclosed in the macro call, all the syntax has to be right there, enclosed in the call. In other words macros are "local syntactic trans…
I see. Good to know, that people have thought about that before. It would make macros even more powerful. But I am not quite sure, (a) what misuses it would encourage or at least enable and (b) how often one would need that power or how often it would be better than some other workaround. But it did come up sometimes when I did something with macros, having me think: "But how to do this???" and not finding a way, other than having the macro be in an outer scope/higher up scope, so that it has more info to work with.
I guess such a macro system might also lend itself better to implementing type systems. Which makes me think of typed Racket. But I think they are rather using source code location info from their syntax object to look up surrounding context, or are using some kind of global state to store info for inference. I don't know this for sure, because I have been unable to understand TR. Maybe someone can chime in on that.