I want to write a macro that expands differently depending on the pattern following it. Specifically I want to use it to allow a more readable notation for quantum mechanical states, e.g.
% Non-working example
\def \m<#1| { \left\langle #1 \right|}
\def \m|#1> { \left| #1 \right\rangle }
\def \m<#1> { \left\langle #1 \right\rangle }
\def \m<#1|#2> { \left\langle #1 \middle| #2 \right\rangle }
The way LaTeX works, it can expand only one of the definitions. If I skipped the last one, a possible fix would be to change the catcode of <,|,> to 11, but that brings issues of its own (e.g. by breaking \ifnum .. < .. forms).
Is there some facility in latex, maybe through a package, that allows matching a single macro to multiple patterns of subsequent tokens?
Clarification Because it came up: I don not want to define commands \bra, ket, etc, or rather this is what I did so far. I am trying to move to a solution that results in more readable code and while writing \bra <\psi_i| \Operator \ket |\psi_j> would be a step towards that target, I'd prefer a form as close as possible to <\psi_i|\Operator|\psi_j>; Pattern matching would be the closest solution I could think of that could work without preprocessing outside of latex.
Furthermore writing complex macros, that analyze the token stream, isn't something I want to do on a per-document level. I'd prefer if there was a package that abstracts such things away, such that even the definition of the pattern remains well-readable for the sake of avoiding unexpected behaviour. If TeX's \def natively supported pattern-matching, the example code above would suit that requirement.



\m<#1|different from\m<#1|#2>? (We can look after a|for 'something' but will need a clue, for example is the first case always followed by a space?) – Joseph Wright Feb 19 '16 at 10:14braketpackage? – egreg Feb 19 '16 at 10:53|or>. A token by token lookup would be necessary. – egreg Feb 19 '16 at 10:57\mthat checks for subsequent patterns -- while I could do this, it would make the macro hard to maintain and error-prone, and the definition very arcane. I'd prefer a solution that takes a list of such patterns and generates the lookahead-logic by itself. – kdb Feb 19 '16 at 11:56>? – Joseph Wright Feb 19 '16 at 12:03>it should expand according to the<#1|pattern. Basically the idea would be to have a list of pattern rules, e.g.<#1|#2|#3>,<#1|#2>,<#1|,<#1>and expand according to the first that matches the token stream. Of course this then wouldn't be doable by a logic that looks only one token ahead anymore -- and because of the implied complexity, I don't want to implement the logic manually and hope for some pre-existing pattern-matching syntax or package. But your and egreg's answers don't give me confidence that such exists... – kdb Feb 19 '16 at 12:10>. You have to have some restriction on what can be present in#2to allow us to know when to stop! – Joseph Wright Feb 19 '16 at 12:24<is always ultimately followed by>we can grab everything up to>then use a variety of approaches to process the text. – Joseph Wright Feb 19 '16 at 12:27\m*...*where...can have the various forms<#1>,<#1|,|#1>,<#1|#2>or<#1|#2|#3>, then it's doable. But without a fixed terminator it would be very hard and fragile. – egreg Feb 19 '16 at 12:38\parto avoid processing the whole document. If such extensive effort is needed however, I consider writing a preprocessing script for the purpose -- which would avoid issues with arcane macros when submitting to journals. – kdb Feb 19 '16 at 12:41\m{<#1|#2>}? – kdb Feb 19 '16 at 12:44xparseand\tl_replace_all:Nnnyou can define\m{<#1|#2>},\m{<#1|},\m{|#1>}and\m{<#1>}. However I don't see an advantage over\ma{#1|#2},\mb{#1},\mc{#1}and\md{#1}(or better chosen names). – Manuel Feb 19 '16 at 14:18\m{<#1|#2>}closely resembles the typeset form, and that by not having multiple macros I can avoid a large number of verbose macro names in the code. Currently e.g. my code reads something like\BraKetOp < \varphi_{mk} | A | \varphi_{nk} >. Of course the macro name could be shortened, but then remembering the macronames and avoiding clashes would become an issue. Condensing everything into one macro would avoid both disadvantages (apparently though at the cost of hard-to-read macro definitions). – kdb Feb 19 '16 at 15:05