I too was thinking of the problem with space in an operator…

Maybe what’s missing in my <#> suggestion is that the choice of the space character as a separator is far from obvious, and I guess that’s what you’re saying about “mental baggage” naming the operators for easy reading.

I suppose you could use sepSpace and sepColon as operator names.

parseAddress = Address <$> hexStr `sepColon` hexStr

parseRegion = MemRegion <$>
    parseAddress `sepSpace`
    parsePerms `sepSpace`
    ...

Still, an actual space/colon character would probably be clearer. For colon, you could use <:>, but what for space?

parseAddress = Address <$>
    hexStr <##> '-' <*>
    hexStr

better reflects the structure of the maps file than hiding away the separator inside an operator. I also find it doesn’t require me to carry a lot of “mental baggage” when reading the code (I suspect this is the thing that’s been bothering me with the love of introducing operators that seems so prevalent among Haskell developers, thanks for helping me put a finger on it). However, your persistence might be paying off I’m warming to the idea. I just have to come up with a scheme for naming operators that allows easy reading of the code.

I also don’t want to hide things, e.g. I don’t want to introduce a function that turns (a <* char ‘ ‘) <*> b into a <#> b.

I’m puzzled about this comment. Aren’t all of your definitions (as well as much of Parsec and other Haskell libraries) “hiding things”?

What appeals to me about a <#> b = (a <* char ' ') <*> b (and similarly for, say “a <:> b“, is that it captures the combination of a character separator and <*>-style application. As your example illustrates (and hadn’t previously occurred to me), this combination is very common.

BTW, thanks much for adding the “preview” button.

Good work !