@JosephWright got the __tl_act:NNNn code prototype ready, is less hacky than I expected. Will put it in shape maybe this evening, then I'll create the PR.
@JosephWright I think I'll have one restriction left: The first three arguments of \__tl_act:NNNn (the functions which should be applied in the different cases) can't be \__tl_act_result:n, but the fourth argument (the user provided stuff) can be arbitrary.
@JosephWright and the three functions must not expand to \__tl_act_output:n or \__tl_act_reverse_output:n followed by an \__tl_act_result:n (the output macros still work with a delimited argument, but when they get called the contents of the fourth argument will be in braces).
@Skillmon -- If everything works out, the talks should be available later on the TUG youtube channel. (I'll have to look at some of them that way. The morning start is 03:00 here on a couple of days, and I am not awake before 06:00 and hardly coherent before 09:00 and even those times are questionable.)
@JosephWright I just realised my implementation builds on an undocumented feature of \tl_head:n, the fact that it needs exactly two steps of expansion (it is only documented to be x-expansion safe).
@JosephWright Well, it always (meaning since I fiddle with kernel code) was this way (but the :N version needs more steps). I can also document this similar to how \tl_count_tokens:n documents the hack that \__tl_act:NNNn terminates with an \exp_end: internally.
@JosephWright I'm now a convert to tcolorbox in its poster mode. I used to use InDesign, but it's expensive and proprietary, and the open source alternative is not really very good.
@AlanMunn I've used beamer for some time: I'll have to look at tcolorbox. I guess I raise InDesign as I tend to want to avoid 'paper on the wall' stuff, so think of posters as ideally needing a graphical tool
I went looking, because I was irritated that \LetLtxMacro didn't complain if the macro was already defined. But apparently \NewCommandCopy does complain.
Hello, I just wrote an answer to https://tex.stackexchange.com/q/586980. While doing so, the question was closed. Can it be re-opened so I can post my answer? My answer is about doing it with \box, \vbox, \hrule and \vrule only.
@JosephWright Thank you. Now I posted my answer, which, I suppose, is definitely not the way in which the teacher wanted the homework done. Probably it can now be closed again. :->
@StefanKottwitz Ouch! I didn't notice the date... I shouldn't have gone into internet while post-concussion-syndrome and whiplash are still affecting my (ap)perception. :-(
@FaheemMitha You can use curly braces with \NewCommandCopy and for consistency's sake, I would tend to prefer \NewCommandCopy{\NewName}{\OldName} over \NewCommandCopy\NewName\OldName. Whenever there's a single token, (character or commandname), you can drop the braces. \let being a primitive operates directly on tokens and will let you even do things like \let\foo=b (the = is optional) and have \foo be equivalent to typing b.
@DonHosek Personally, whilst I get Lamport's motivation, I think there is an issue using braces around arguments which must be single tokens - it leads to people thinking they can use more than one token; so I omit them
@JosephWright That's one of the things I'm eliminating in finl. My big question is whether to allow someone to write, e.g., $\frac1\sqrt{x}$ instead of $\frac1{\sqrt{x}}$` since at parsing time finl will know about the arguments to \sqrt. The biggest thing making me hesitate is that requiring the braces will make it easier for users to remember the braces in 2^{2^n} where I don't see anyway to avoid requiring the braces for the sake of clarity.
@DonHosek -- In that case, recommend {if not require) the braces. It makes it easier to remember them where they're absolutely needed, and also, treating both numerator and denominator the same reinforces the principle.
@DonHosek I certainly would not allow that. The fact that x^\frac12 sort of half works in latex is a mis-feature that would be good to make an error not an example to be copied. Even if the typesetting parser knows the syntax of each command and can parse it correctly, human readers can not, nor can syntax highters context sensitive editors, convertors to other formats etc.
@DavidCarlisle Good point. And I have the ability with finl to just say that the braces are required always even since it is, after all, a from-scratch parser. It's also something that is exposable to other applications, so a finl IDE would be able to use finl's own code to do syntax highlighting and code completion hinting. I imagine it could even be incorporated into a language server protocol.
(this latter, makes it likely that perhaps I stick to LaTeX conventions, though, since I can see a finl-based LSP being useful to LaTeX users as well.)
@PhelypeOleinik some tourist places boast sun and sand, at the bottom of the pass the village (actually just a farm) proudly claims to be the wettest place in England:-)
@barbarabeeton Well, numerator and denominator would be the same, so you would be able to write \frac\sqrt{a}\sqrt{b} in place of \frac{\sqrt{a}}{\sqrt{b}}, but as I was thinking about the LSP-application of the finl parser, it became obvious to me that sticking with the LaTeX convention would make the parser more generally useful (although then I might have to support the full panoply of xparse argument types).
I can, at least provide a warning/error on something like \frac1\sqrt{a} that would be more meaningul than the current state of things.
@JosephWright True enough. I think that there will be two modes for the finl parser though: One thing that finl allows that LaTeX can't is doing things like \footnote{\verb+\foo+} because it does away with the whole category code thing. The LaTeX-compatible parser may end up being something that shares a lot of code but is a separate entity.
(But I think I want a LaTeX-compatible parser anyway to allow a LaTeX2finl converter program to work.)
@DonHosek -- I don't believe I said to allow omission of the braces. What I was really recommending is that they always be used.
@DavidCarlisle -- When you've plowed through all the messages in the mathml queue, let me know. I've got a question of long standing (and an idea that has been long pooh-poohed) that I believe is relevant to the present discussion.
@barbarabeeton One nice thing about writing a LaTeX(ish) parser from scratch is the possibilities it opens up. It's easy enough to either require braces or warn on their absence. It's also possible to write a “normalizer” (and that will likely be one of the first products of finl parser) that would, e.g., convert every instance of $…$ to \begin{math}…\end{math}, change \frac12 to \frac{1}{2} etc.
