Multiple text arguments for pollen command syntax

Computational typesetting
1

The issue of being able to have multiple text arguments has been raised previously, but I wanted to revive the topic and would like to know whether this is something that will eventually be possible as part of the Pollen syntax. (I also faintly remember a different thread with a link to the scribble mailing list, but I am not able to dig it up anymore.)

As an example, what I would like to have is the possibility to supply multiple text arguments to a pollen function like so:

◊ketbra{\phi_+}{\phi_+}

It’s actually a bit surprising to me that it doesn’t work since most tag functions already need to accept a variadic number of arguments.

I am aware that it’s possible to curry the function to do something like

◊◊ketbra-curry{\phi_+}{\phi_+}

but I think that’s

  1. Ugly (arguably subjective) and
  2. a rather rare use case, especially in comparison to the alternative.

I’d like to know whether having multiple text arguments is something that is planned to be incorporated at some point or whether this is not something of interest to the Pollen project. Additionally, I’m having a hard time even roughly estimating how much work this would entail.

2

I share your interest, and in fact made a similar proposal to the Racket maintainers in 2013. They were not persuaded.

In principle, would it still be possible to make this improvement? Sure—it would require forking the @ reader that Pollen relies on and hacking the parser. I have occasionally forked & patched pieces of Racket for better compatibility with Pollen.

But having used Pollen almost daily since 2013, I’ve never found the limitations of the @ reader to be a hobble. Thus, mucking with the @ reader now seems like a heavy lift for not that much incremental benefit.

Furthermore, there’s arguably no difference between

◊ketbra{\phi_+}{\phi_+}

and

◊ketbra{\phi_+ \phi_+}

except for how ketbra itself parses the text arguments.

3

Yes, that is exactly the link I remembered; it’s a bit of a shame that it went this way. The example you give there with crossref is more suitable I think. In general I find the workaround provided in the mailing list thread unconvincing.

Of course it’s possible to parse the input with the tag function, but I feel like that makes it unnecessarily complex and a bit unintuitive.

Just so I understand how things work: the Pollen code calls make-at-reader from scribble without any further modifications, correct? I thought that there were some minor changes to the scribble reader, since it didn’t allow a different command char than @, but apparently that is no longer the case (seeing as there now is an option for setting the command-char). So the way I see it, the function make-at-reader would have to be adapted in order to facilitate the functionality.

4

What if the input is something like this?

◊my-command{I ◊em{like} sauce!}{I like ◊em{bread}!}
5

Being able to set an alternative command character was another early request of mine (that was apparently persuasive).

That sounds right. I’ve never tried it.

PS It would also be possible to make this notation work by redefining #%app:

◊ketbra{◊{\phi_+}◊{\phi_+}}
1 Like
6

The curly braces will allow any number of nested subexpressions, so this is fine:

◊my-command{I ◊em{◊strong{really} like} sauce!}

The limitation is not being able to chain them left to right.

7

In my understanding, it’s not that “they were not persuaded” (assuming that “they” meant the Racket team). It’s just not possible to do so satisfactorily while maintaining backward-compatibility.

Matthew suggested in the email thread that:

@foo[1 2]{3          
4}[5 6]{7
8}

should be parsed to:

(foo 1 2 "3" "\n" "4" 5 6 "7" "\n" "8")

This way is backward-compatible, but it’s not what people would normally expect. For example, @flirora’s example code:

◊my-command{I ◊em{like} sauce!}{I like ◊em{bread}!}

would be parsed as:

(my-command "I " (em "like") " sauce!" "I like " (em "bread") "!")

and it’s not possible to find what the original two blocks are anymore (without further workaround)

In Rhombus (or more accurately the Shrubbery Notation), @-expression was revamped so that the body parts are collected into one single list value. I then made a suggestion to the team that due to the new parsing, the multiple text blocks could now be supported without any issue, and they were persuaded. It’s now implemented.

1 Like
8

For the sake of clarity & not raising false hope — this notational improvement is part of the experimental Rhombus project, and isn’t being propagated back to standard Racket, right?

9

That is correct.