[kazinator]

  #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 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 x) -> (p (x))

  (q x y z) -> (p (x y z))

q no longer loses to #p:

  (q x)
  #p(x)

[asQuirreL]

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).

[daveliepmann]

Isn't this the exact same number of keystrokes? 'Shift-3 p' versus 'Shift-9 p' on my keyboard.

[zamadatix]

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.

[eviks]

The closing parenthesis is auto inserted, so also the same?

[dkersten]

paredit, parinfer and whatever other Clojure/lisp editing tools exist make this trivial though. Editor macros also exist to wrap expressions in calls.

[kazinator]

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.