!rename( SYMBOL )( NEW NAME )

[tajmone]

It's just an idea that flashed into my mind, but I think it has some interesting potential uses:

!ren[ame]( SYMBOL )( NEW NAME )

This would allow to change the behavior of "higher level" user macros by swapping names of some of their internally used macros.

For example, a !format(TEXT) macro could carry out some text manipulation via other macros:

!def(justifyLeft)( [...] )
!def(justifyRight)( [...] )

!def(format)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
!justify(!1)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

At any point the behavior of !format could be changed by !rename:

!rename( justifyLeft )( justify )
!format( SOME TEXT )

!rename( justify )( justifyLeft )
!rename( justifyRight )( justify )
!format( SOME TEXT )

... this approach can avoid using lots of !if, !ifdef checks al over the place.

[CDSoft]

!rename would be a specific way of redefining macros. e.g.: !ren(X)(Y) is equivalent to !def(Y)(!X(!1)) (for macros with a single argument). !def requires a few additional characters but is more powerful. It can generate new macros instead of simply reusing existing ones.

[tajmone]

Right. And I guess that a further !undef would allow to destroy the original macro.

Would it also work with complex macros, via !def(Y)(!rawdef(X))? This should allow to transpose the whole unexpanded definition of the original macro.

I think that if there is a good case for a !rename macro, a built-in implementation would allow preserving also the macro's documentation, if present, and to do it in a single step and spare manual destruction of the original.

As I said, it'sjust an idea that came to my mind while I was working on a particularly complex macro that could have benefited from a rename built-in macro, so I was wondering if it would be a good choice to implement it, and what its pros and cons would be. When working at complex tasks, I often go over all the built-in macros and try to think which would be the easiest way to achieve what I need, with as few steps as possibile; and during these moments I often end up thinking "if only there was such and such a built-in macro...".

But of course, this is not a proof of any real need, except that it proofs that a stuck person (ie: me, in this case) often is lazy and/or doesn't see the possible solutions in front of him with the tools at hand (and that if you're convinced that all you have is a hammer, everything starts to look like a nail). But at the same time it could be a point in favour of more specific tools (ie: having a screwdriver might be better than a hammer for screwing screws — if the screwdriver isn't actually there, or if it looks like a hammer).

The whole idea is about built-ins that allow operations on names of already present macros, like !rename(OLD NAME)(NEW NAME) or !swap(X)(Y). Do you think that introducing such features could open up some interesting potential uses?

I tend to see some potential in such macros, especially when reusing existing macros which one wants to behave different in a given context. This is a situation I often face in my usage of PP: I want to reuse some macros files from another project, but I'd like to tweak their behaviour for the current use without ending up maintaining different versions of the same macros — for example, migration to PP v2 forced me to update lots of files all over the place, using cut-and-paste operations, whereas importing from mixed sources and renaming macros would have proven easier. But this is because I tend to focus on specific areas for which I have lots of macros "modules" I keep updating and reuse.

[CDSoft]

Sorry for the late reply... Please keep in mind that pp is not supported anymore, it's hard to deploy. For new projects I suggest ypp which is is based on a Lua interpreter and way easier to compile and install and binaries are easier to produce (thanks to zig) and deploy (see hey).

ypp uses Lua. Defining, redefining, undefining variables and macros (that are just Lua functions) is way easier than what pp can do.