@SašoŽivanović I'm wondering if this is safe?

Or if there's a better approach?

@SašoŽivanović Also, why is it necessary to define

label/.style={tikz={\path[late options={%
        name=\forestoption{name},label={#1}}];}},
  pin/.style={tikz={\path[late options={%
        name=\forestoption{name},pin={#1}}];}},

rather than

label/.style={tikz+={\path[late options={%
        name=\forestoption{name},label={#1}}];}},
  pin/.style={tikz+={\path[late options={%
        name=\forestoption{name},pin={#1}}];}},

The latter seems to make life prima facie easier: labels and pins can accumulate, as they do in TikZ and will not overwrite any prior uses of tikz or tikz+ etc. See

- the EDIT EDIT bit at the bottom.

@cfr It seems safe, yes. But you have to know I know nothing of beamer ...

@cfr That's a very good question. I actually wonder how is it that noone has remarked upon this until now ...

I guess I should consider this a bug and fix it, what do you say?

@cfr Well, again, I'm glad to hear that! Both the ease-of-use, and the 10% is good. ;-)

Actually, I have managed to squeeze a bit more speed out of the system. In my dry runs, .process is now 40-50% faster that a comparable .(wrap) pgfmath. It all boiled down to being careful about how to manipulate TeX's token lists and thereby gave me another idea for a speed-up.

Anyways, the code is in a state of a total mess right now: today is the git rebase day, hopefully it's successful and I can truly publish the bugfix release. The big release will indeed have to wait a bit more.

@SašoŽivanović If there's no good reason, I'd be inclined to think it buggish. However, I'm also unclear about the purpose of afterthought which does use tikz+? Especially since that's defined right before label and pin, I thought there must be some reason, even though I can't think what.

@SašoŽivanović Excellent.

@SašoŽivanović ;)

@SašoŽivanović I was mostly worried about drawing the tree inside nodes. I think the Beamer side should be OK. (That is, if it works, I think it is probably OK Beamer-wise, though I'm often wrong.)

@SašoŽivanović It would be convenient if Forest label and pin could be used more than once and/or both used and/or be used after tikz(+). It is easy to forget that if I write label in Forest it will overwrite everything, whereas I can write label in TikZ and it just adds to existing annotations. If there's no need for the quirk, it would be good if you would fix it ;).

@cfr Rebase successful, lunch delicious, bug fixed. Btw, do you think a compat key is needed for the label/pin bug? I lean towards not, but then again, maybe I'm just lazy. ;-)

@cfr Btw, I have noticed that you're using children and parent anchors in your package. Given that I'm obsessed with speed, lately: that's slow. So, given that proof trees will probably always grow south, you might want to reconsider using them ...

@SašoŽivanović I was trying not to assume a south-growing tree. In particular, I was trying to allow for the possibility of growing north. I'm not sure whether this is useful, though. If I assume south-growing, I can also take some conditional code out. How much difference do the anchors make?

@SašoŽivanović I wouldn't think it was needed. It would require that somebody was relying on label/pin overriding stuff they'd set with label/pin/tikz and it is hard to see why that would be a useful feature since you could just not set that stuff more easily. Or you could add a note in the docs saying that tikz={}, label={} will emulate the old behaviour if it is desired for some reason. A compat key seems like overkill.

@cfr I just thought you did, as I saw no other example ;-) Anyways, my bad again: they are not slow after all (I was looking at the wrong code, at some other anchor related code), plus the cardinal directions have specialized code so they are really fast. Bah!

@cfr Ok. Tnx.

@cfr I am, still and once again, not satisfied with the location of the section on spatial propagators (not 3.4.3, under "workflow") in the documentation. Do you think it belongs there? Or should I put it under nodewalks? (My argument against that is that they are node keys, i.e. they can be used in the tree specification directly.) Or maybe I'd put them as a subsection of "node keys" (so 3.5.1)?

I started to think about this because I'm moving details about "draw tree" into its own subsection (3.4.x).

@SašoŽivanović Well, I am and I'm not. I don't really think the package useful for other cases, but I figured I might as well avoid hard-coding south if it is easy to do. But if hard-coding it would be faster, that would be a reason to rethink.

@SašoŽivanović It is a bit confusing that it comes before the introduction of node keys. But putting it with nodewalks will make it seem more complicated than it is, I think.

@cfr 3.5.1 then, right?

And while I'm finishing up this bugfix release, I'm still thinking of performance issues, specifically my fuckup concerning how easy it is to fire up the pgfmath parser. I hope you're up for some discussion ... ? No rush, though.

@cfr Or maybe in a big section, between "Formatting the tree" and "Nodewalks"?

@SašoŽivanović Sure. We're in the middle of dinner right now, but in a bit would be fine.

Dober tek!

@SašoŽivanović I think before formatting the tree because lots of the examples there use things like for tree....

@SašoŽivanović Sorry, but I only do English and Welsh. A very little German and about two words of French.

@cfr But there's context, so you know what I mean! ;-)

@SašoŽivanović Galla' i ddyfalu ;).

@SašoŽivanović Anyway, we just finished washing up, so ...?

@cfr That's the spirit! ;-)

@cfr At first I thought: I screwed up, but ... just let it be. But now, we're actually not letting it be. Consider the proliferation of ' variants (which abound anyway...): if, where', filter', while, until' etc.

And I believe that even if what the regular user does (a couple of calculations now and then) usually won't have a great impact on speed, I think we've seen that for a package based on forest it can make a difference. As you said, 10% is not negligible.

@SašoŽivanović Let what be? The washing up? I guess you mean something to do with pgfmath, but I'm not sure what exactly.

@cfr pgfmath, yes.

Let me explain.

@SašoŽivanović Also, there are things which it is just more difficult to do with the pgfmath stuff. And it makes it much harder to see what you're doing when things get complicated. Polish notation is one thing, even in reverse, but wrapped pgfmath arguments end up after the code which uses them.

If I was starting from scratch now (read: without a user base), I guess I'd handle assignments to count/dimen options/register just the reverse of what I did then. The default would be a simple TeX assignment (or maybe eTeX's \numexpr/\dimexpr), and pgfmath would have to be explicitely called, via ./pgfmath or maybe via option=$pgfmath expr$.

@cfr Yes I've definitely put the arguments of wrap pgfmath on the wrong side!

Not I'm trying to think of something to do, in order not to have to double every key taking a numeric/dimen argument. 'Cause that also doesn't help with ease-of-use. And it's entirely too easy to forget the 's.

So it's not so much wrapping I'm concerned about (the old pgfmath wrap stays as a relic, ok) but more the assignments and numerical/dimen arguments to various commands.

I'd like to have a simple, systemic solution, that would also be faster.

@cfr Am I making any sense at all?

@SašoŽivanović Yes. You want something like \ExplSyntaxOn and \ExplSyntaxOff ?

@cfr Hmm, that's a thought.

One problem though, or maybe they are two. People develop their own styles and kind people like yourself even do it for others. ;-) Now if there were two systems, there might be duplication of work.

Another issue is that while expl3 syntax is so obviously different from LaTeX2e, this wouldn't be the case here.

So not easy to tell which one you're using.

Though on the other hand, the new syntax would obviously be the preferred one. So, in a way, you have proposed a glorified compat key ;-)

@SašoŽivanović This isn't really true. The difference between the processified version and non-processified version is fairly obvious - where it isn't obvious is where it doesn't actually matter which syntax is being used.

@cfr Yes, whereever there's the .process handler, things are obvious. But then there are also the new if' and filter' etc. who use .process implicitely. And if you think about it, you'll see that using the handler would make little sense in most of these cases.

@SašoŽivanović I don't exactly understand this. If I develop a style, why would I develop it twice? Why wouldn't I pick one syntax and use that? Or switch in the middle, if that's convenient. I have a class file in which I have 11 occurrences of \ExplSyntaxOn/Off. Although it is true that I've been rewriting bits in the new syntax, I see that as a replacement and not a parallel version. (If I might need something, I dump it in a legacy file which I can optionally load.)

@SašoŽivanović I didn't mean that. I meant that, for example,

 root,sort by'={{O}{y},{Ow1+d}{x}{-##1}},sort'={filter'={descendants}{{OO!&}{proof tree rhifo}{proof tree phantom}}}

obviously uses the new syntax. I can tell that at a glance and not because I notice the apostrophes (I don't), but because Ow1+d and OO!& are distinctive.

It is less immediately obvious with something like {O}, I admit.

@SašoŽivanović Even with something like

tempcounta/.process={RRw2+n}{proof tree jcount}{line no shift}{##1+##2},

what tells me at a glance that this is processified is not .process but RRw2+n. Maybe that's just me.

@cfr Now I really had to think hard to realize what I believe to be a hole in your argument. Wherever there is new syntax, like ROOw3, I agree with you. However: assignments. Plain assignments. I don't want to change them. ---And that's what's different from the expl3 team. They changed everything, internally, because they had no reason to stick to anything: their users are programmers.

(But they are taking great care, as far as I get it, that the end user experience will be the same, or at least comparable).

@SašoŽivanović One of the issues with the apostrophes is that they are indicating different things in different cases, as well as being difficult to spot.

But I need people to be able to write s sep=5pt.

@cfr Oh yeah, you're right on both counts. Have you noticed how new nodewalk step names are much more verbose? ;-)

@SašoŽivanović I use it and I'm not. But now I'm confused. If you implemented an equivalent of \ExplSyntaxOn, why would that affect people's ability to write s sep=5pt? For one thing, that will work whether it is a dimexpr assignment or pgfmath, so it makes no difference. For another, if you need to switch the new syntax on explicitly, then a user who doesn't care about that stuff won't throw the switch.

Isn't the main point to enable people who write an extended style/package to switch to the new version?

@SašoŽivanović Yes. Although I find the long names harder to use than the short names because of the commas.

@cfr I guess I'm doing a bad job explainig my messy thoughts ... I will try more and harder.

@SašoŽivanović Yes. But if you write \ExplSyntaxOn then the experience is not the same ....

@cfr Now this I don't understand. I thought they were just worse because they were ... longer?

@SašoŽivanović More because you need to remember to protect things.

!uu.content=something

!{parent,parent}.content=something

The u -> parent is easy. It is the { , } which makes it trickier.

@cfr Ok my problem is not having a new piece of syntax. This is what's happening with .process anyway (albeit not on thr expl3 scale:) My problem is that I wish to fix my old mistakes. In particular this one: that pgfmath wouldn't be invoked unless explicitely required.

@cfr Yes I see now. That's another short vs. long. Maybe I should simply try to write a faster parser for that ;-) Actually, the .process stuff gave me an idea ... but the situation is a bit different, as in short nodewalk step names, if the sequence is not correct it must pass it on (treat it as a tikz key, eventually).

@SašoŽivanović Hmm... I don't see how you can do this without either breaking existing code by other people or greatly complicating yours (e.g. by seeing if something can be parsed without pgfmath and then using pgfmath if not so that the user doesn't need to explicitly invoke it).

@cfr Now you have written succintly my thoughts in three lines. I'm trying to decide which is worse, or have you convince me (again) to give it up for all times! ;-)

@cfr But I'm also trying to figure out a way that if I do something, it would be as painless for the users as possible!

I'm not really fussed about complicated code. Past that point, already ...

@SašoŽivanović That is, I understand the problem better now. But that problem certainly can't be solved with an \ExplSyntax solution because the whole point of that solution is to not affect what users have to write at the document level. (Also, even programmers would presumably get pissed off if they had to explicitly mark every space in their journal articles.)

@cfr \ \space_ :-)

@SašoŽivanović But it would also make it slower and it would (probably) increase the bugs because complex code is harder to maintain.

@SašoŽivanović Won't work. ~ is breaking space.

@cfr But I want to do it primarily because I want it to be faster! So that would be the primary objective.

Maybe there should be a \space:.

@SašoŽivanović I know.

But look, you want the following:

Of course, there would be specific cases where it would be slower. Like when the system figures out it can't parse it and has to invoke pgfmath after all. ---Actually, that's what pgfmath is doing internally, as well. First it tries the simple algorithm (which is most of the time enough), then the slow complex one.

1. Users can write trees and styles just as they did before and it will all work the same.

and

2. Users have to explicitly invoke pgfmath to get pgfmath.

@cfr Sorry, I was again mixing two trains of (my) thought. My two options are as follows.

@cfr Actually, three options.

(i) Everything stays the same for the end user but internally, I complicate stuff by trying to figure out if pgfmath is needed or not.

(ii) Users need to explicitely invoke pgfmath. Not everything will work anymore. (unless they use the compat mode)

(iii) There is a gradual transition from (i) to (ii). (deprecation warnings etc)

I'm just so pissed off with myself!!!

@SašoŽivanović I'm dubious about this option. I don't know how robust it will be and any time code tries to second-guess what people mean, stuff gets complicated because there will always be corner cases. If you were writing an Office plugin, people would expect it. But one of the things I like about LaTeX is precisely that it doesn't do this. And when a package does, I tend to find an alternative or write my own. I think you'll end up with many complications codewise for something...

... which will inevitably never quite manage to do what it says on the tin.

But I know nothing about programming ... so you shouldn't listen to me ...

@cfr You do. And I'm listening to you. And you're right, of course. ---Actually, while delving into pgfmath code today, I realized that even they don't cover all that plain TeX does. For example, pgfmath doesn't accept units in caPiTal letters ...

@SašoŽivanović Do you have any sense of how much would break if you did this? There are presumably lots of cases where it won't make a difference - like the l sep=5pt case. Unless you think only more sophisticated usage will break and that most stuff will still work, (ii) strikes me as unnecessarily destructive. I don't want your update to break my thesis at the deadline even if it would save me a couple of minutes if only I knew how to fix the damage.

@SašoŽivanović I didn't realise that plain TeX did. But I'm not keen on capital letters.

[That is, I only use them when I have to, so I'm not likely to try units in capitals when lowercase units work fine.]

@cfr Corner cases! ;-)

@SašoŽivanović Also, people may be using apostrophe versions of things, so I guess you need to decide whether to deprecate that syntax, too.

@SašoŽivanović Of the 3 options, I think:

(i) This way madness lies.

(ii) This way other people's madness lies.

(iii) Sounds reasonable.

@cfr Reason lies between two madnesses? Is this some philosophical doctrine? ;-) But I agree. Well, at least about (i) and (ii). I'm not sure about how reasonable (iii) is, I think I more wish you were right...

@cfr Well, how much would break really depends on what I did, precisely. If I simply adopted TeX assignments, all hell would break loose, like l sep=0 wouldn't work anymore. So certainly something smarter than that.

But I'm not entirely clear how the transition would work. If you want, say, filter to eventually mean processified filter, what do I do when I see my use of filter is deprecated? I need to be able to change my code to the new syntax, but I'm not clear how that can work if the new syntax will also use filter.

@cfr The reason I adopted pgfmath in the first place is still valid: I want the users to be comfortable, as much as possible. And, yes, speed is still secondary to that!

@SašoŽivanović I said Of the 3 options.... It might be a trilemma. I think it is the least bad of (i)-(iii). Whether it is reasonable in a more absolute sense ....

@cfr Something like filter={nodewalk}{$pgfmath expr$}.

@cfr Sorry, that's for "pgfmathizied" of course. But you get what I mean, right?

Put some signal in the value, not in the key.

@SašoŽivanović If I have filter={nodewalk}{pgfmath expr} and I get a warning, then suppose I want to use the processified version. How do I do that?

@cfr Hmm, good point.

@SašoŽivanović For something like filter ... I don't really see what is being gained.

For things like l sep, I can see the case for migrating things so that eventually l sep= uses \dimexpr or whatever rather than pgfmath. Because most of the time when people write l sep=, they just use a dimension anyway. But for cases where current usage cannot be parsed except with pgfmath, I do not really see the case for forcing users to write filter={}{$$} rather than filter={}{}. Why can't you instead put a signal in the value for the non-pgfmath version?

@cfr Well, filter is only one example. A more complete list would be: count and dimen assignments, if and where, many loops, aggregates, probably I forgot something. And hell, even user defined styles.

@cfr I could put a signal for the .process version, that's a good idea. The problem is that the "plain" version (like in repeat, maybe) should also be without the signal.

@SašoŽivanović But why can't you implement a signal to use the new stuff rather than forcing people to add a signal for pgfmath? From an end-user perspective, this just seems to be breaking my code for the sake of it. And my code won't even run faster after I add the $...$ because I'd have to do more to get the benefits of the new stuff. So nothing is really gained from pissing people off because most people will just add the $...$.

@cfr The point should be to make them happy because it runs faster :-) And they wouldn't need to add $...$ many times I guess: most of the stuff is really just plain l+=1cm.

@cfr I'm starting to see what you mean.

@SašoŽivanović So what if you have two signals - $...$ for pgfmath, something else for .process and nothing for the default handling. Then you decide what the default handling should be on a case-by-case basis. For things like l and s sep, the default should be process because this will almost always work. For things like filter, the default should be pgfmath because existing code will always break otherwise.

There's a big difference between cases where the system expects a count or dimen value, and cases of a complex (mostly boolean) expression

@SašoŽivanović That's why I think you should handle them differently by default.

You're absolutely right. There are cases where pgfmath should be the default. It's just not assignments.

So something like: filter={...}{pgfmath} and filter={...}{?ORw2+n...} ?

What about simple assignments then: s sep=3pt and s sep=$l_sep("!blabla")*2-3pt$ and s sep=?ORw2+d. And a (long) transition period when the system tries (but very conservatively!) parse and if it doesn't succeed, calls pgfmath and yields a deprecation warning?

@SašoŽivanović Yes! But if you are going to use $ to signal pgfmath at all, I think you should support filter={...}{$pgfmath$} as well for consistency.

I have chosen ? because it is a pgfmath operator, but an infix (if then else = x ? y : z)

@cfr Definitely.

Handlers (.pgfmath, .process) would still exist, in any case: they are needed for toks options.

@SašoŽivanović I think it would be easier if the signals were structurally similar i.e. ?...? like $...$.

@cfr There's one thing I like about $ and one that I don't. The good thing is, it's traditionally associated with math in the (La)TeX world. The bad one, you need two of them. Both for the consistency with the inspiration and, even more importantly, for font locking tools! ;-) (Hmm, this might be an emacs-specific term ... syntax colorizers or whatever they are called.)

@cfr Similar train of thought I see.

@SašoŽivanović Yes. Although I suspect the number of people using s sep=<pgfmath> rather than s sep/.wrap pgfmath... is fairly small.

@cfr I would actually prefer just a single symbol at start.

@cfr If that's the case, then I have been worrying in vain!!!

Is this really the case?

@SašoŽivanović :Then I think you need a different symbol, ideally, for pgfmath. It is going to be confusing if you need 2 signals for one and 1 signal for the other. But you can't have just one $ for sure.

What about a ) ;-)))))))

@cfr On the serious side, * might work for the same reason as ?.

@SašoŽivanović Yes.

My emacs got completely confused recently when I enclosed an environment containing some $..$s into a {group}. The colors were reversed from that point on!

Or /

@cfr Nope!!!!

Unless you want to protect it in braces ;-)

@SašoŽivanović Won't you need to protect it anyway? Or only for the process version?

@cfr I see, in most applications it is in one of the several args anyway. Well, just to be on the safe side, I wouldn't want to (ab)use pgfkeys path separator.

@SašoŽivanović Kile does this sometimes, too.

@ might have a good connotation for .process? As it's "more for programmers"?

@SašoŽivanović \bracketset{action character=@} ?

Can you believe that pgfmath parses @4@2@. As 42. Must be set as ignore category.

@cfr There is no default bracket action char. You think anybody actually uses action chars? I programmed them when forest was still very small ... definitely way before dynamic nodes.

Ahh I see now ... in examples!

@SašoŽivanović I do. prooftrees uses it and I got my suitable character from your manual. I've also used it in answers on this site.

@cfr Wow!

@SašoŽivanović No default, but @ is the obvious choice since it is the one you use in the manual. So it is reasonable to assume that whatever might be a bad choice, @ will be a good choice ;).

@cfr Yes so @ is out. But I've found ^.

@SašoŽivanović Or _ which is Expl3-ish ?

This looks good, but what about _ in .process?

I know it can't be any syntactic confusion, but there might be human confusion.

Unless _ in process is replaced by - maybe ... I was already toying with the idea, as + and - would then do the reverse operation. However, the problem then is backward compat.

@SašoŽivanović You're right. I'm already confused. And _ can be the first character ...

@SašoŽivanović You've not released this, though, have you? I don't exactly see how they'd do the reverse. _ does nothing to another argument. + does something else to the current argument. Don't they?

@cfr It's certainly possible to conceptualize it this way: _=nothing, +=chain. But there's another way: _=move (Turing) head right, +=move head left.

@cfr Speaking of + in process. I think wN+ idiom is used very often. Maybe too often, and would be better if w didn't "move the head right"? I counted in prooftrees: I think only in 6 cases out of about 30, you actually needed the head to move, because another wrap followed. The rest was wN+n, or the end of instructions.

@SašoŽivanović Oh, OK. Yes, I see. I think of it as WFF 'n Proof, so I guess I think in terms of the first.

@cfr I really need to get that game!

So we have: ?*^_ and there are also <>˙. Maybe also ;. Does any of these strike you as ... iconic? _` for process is best so far I think.

@SašoŽivanović 6 versus 13. But that might be an artefact of my coding or this particular case. It's a pretty small sample size.

prooftrees4744: 6/36.

@SašoŽivanović I agree about _ for process. I'm not sure for pgfmath but <> seem potentially confusing as they are used in so many ways already, including in documentation etc.

@cfr So I'm counting where wN is immediately followed by an operation on an argument that is not the result of the wrap.

@cfr I sort of like ?, but not so much as a pgfmath signal, but rather as a prefix. You know, to keep our options open. ;-) Reminds me of ? in the regex groups(?...)

@cfr _ for process, then. And I change the current _ into -. (Though I'd leave it in the code for a while, as it can't hurt, with a deprecation warning?)

Or maybe not even that, as you and me are probably the only people who have ever used .process (args) ;-)

@SašoŽivanović Unless you think someone else is using it, it just invites trouble. You'll break code later which would have immediately given an error if you didn't allow it in the first place.

I'd rather know immediately that I've typed _ rather than -. Especially since they are the same key, so it is an easy typo to make.

@cfr It has only been two months ...

@SašoŽivanović But it is not on CTAN, is it?

@cfr Of course it is. v2.0.0

@cfr Actually, > might not be a bad choice either: it's pointing in the direction your arguments are being processed (at least in simple cases like {OO_R})

And & for pgfmath?

Hmm, not &. That strange comment about spreadsheets in the roadmap in the doc is actually serious.

@SašoŽivanović In .process args, you mean. Yes, I'd forgotten that.

@SašoŽivanović But it is also a character in the syntax. Although there's less room for confusion than with _. But something not available there at all would be clearer. Maybe.

@cfr I'm actually quite proud that progress from .process args to .process is backward compatible! (Well, so far.) I just think shortening the name will not hurt.

@cfr True. (Well, at least it can't be the first one.)

`\\\`?

@SašoŽivanović I like _ partly because it doesn't make things look cluttered. But needing to change the existing _ is probably bad, so maybe > is better.

Forget about \, cannot type exactly two in this chat ;-)

\\

Hmm.

@SašoŽivanović ??

I was trying to suggest \\ as our "character".

But I failed to enter it as code. Let me try again: `\\\`

Nope. `\\`

AAah

You need to type in three of them. Very intuitive.

@SašoŽivanović Would that be needed in Forest?!

@cfr No, but imagine asking a question about it!

| > \\ ~

@SašoŽivanović If you type back tick - backslash - backslash - space - back tick it works except for the extra space.

@cfr Crazy system. I would like ~ if it wasn't so difficult to type on Slovene keyboard ;-(

@cfr Speaking of keyboards, I think we kind of went through it all!

@cfr It really isn't fair that $ can't be alone. Maybe a request to the developers of colorizers to support forest? :-)

@SašoŽivanović I would like | if it weren't so difficult on a UK keyboard. I'm not using a UK keyboard right now, but I do. (I still type faster on a US keyboard and Lenova offered that for my laptop even in the UK.)

@SašoŽivanović It isn't even as though you could use two for parity with \\ .

@SašoŽivanović > is similar to the xparse process argument symbol isn't it?

@cfr Yeah my | is also not best. But ~ is worse. And actually, the bloody backtick as well. My backtick is "rightalt7 rightalt7". Yes, twice :-(

@cfr I had no idea. Perfect!!!

@cfr And the circle of inspiration is closed.

@SašoŽivanović That's crazy. Can't you change it?

@cfr I could use the US keyboard. But we like to suffer around here ...

Honestly, programming can be hell sometimes on our keyboards.

Each argument processor is specified by the syntax >{hprocessori} in the argument
specification. Processors are applied from right to left, so that
>{\ProcessorB} >{\ProcessorA} m
would apply \ProcessorA followed by \ProcessorB to the tokens grabbed by the m
argument.

@cfr Just checked the doc myself, too. So cool.

Though ... Processors are applied from right to left upst!

^^ From xparse's manual. Too bad it doesn't use reverse Polish notation, but nothing's perfect.

@SašoŽivanović You could always use < instead.

@cfr Yeah sorry about the "reverse" but it seemed natural. Comparing and conjoining etc sutff you've already processed ...

@cfr Nah, the direction seems right. They fucked up! ;-)

@SašoŽivanović So > for process and what for pgfmath?

Any ideas?

@SašoŽivanović I think I prefer * to the other suggestions, but I don't have any reason really.

@cfr I was thinking of * as well.

@cfr But I'm not sure I really like it.