I don't think this is a good enough reason to write a macro. Macros should be used for doing things one otherwise couldn't do and have sufficient advantage. For example the threading macro used right there in the code is worth writing a macro, because it makes things easier to read and follow and couldn't be done like that using functions, because of the order of evaluation and argument injection that the threading does. Another example are new define forms, which by definition cannot be expressed resulting in the same syntax using functions. Defines are special. Another example for a justifiable macro could be a timing macro, which relies on changing the order of execution, because when you write (time something) then something would be evaluated before time is ever called, if time was a function.
But the #p in the post seems to me to be a dubious choice for writing a macro. Too specific, too easy to use something else, too much confusion, too little gain.
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 lead.
The thing is, we can make the printing operator take arguments and turn them into an expression. Suppose we make a cousin of p called q, such that:
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).
I don't think this is a good enough reason to write a macro. Macros should be used for doing things one otherwise couldn't do and have sufficient advantage. For example the threading macro used right there in the code is worth writing a macro, because it makes things easier to read and follow and couldn't be done like that using functions, because of the order of evaluation and argument injection that the threading does. Another example are new define forms, which by definition cannot be expressed resulting in the same syntax using functions. Defines are special. Another example for a justifiable macro could be a timing macro, which relies on changing the order of execution, because when you write (time something) then something would be evaluated before time is ever called, if time was a function.
But the #p in the post seems to me to be a dubious choice for writing a macro. Too specific, too easy to use something else, too much confusion, too little gain.
But what if the argument is a parenthesized expression:
#p is back in the game with a 1 char lead.The thing is, we can make the printing operator take arguments and turn them into an expression. Suppose we make a cousin of p called q, such that:
q no longer loses to #p: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).
Very smart. But also a good example of why macros are brittle.