Input/Output names

[randomeizer]

I see there is some experimentation with using typealiases for Input and Output (as ParserInput/ParserOutput and PrinterInput/PrinterOutput).

I agree it's quite confusing having print(_ output: Output, into input: inout Input), but not sure that having multiple aliases is the best option either. Especially given that there are basically 3 names for each of the input/output types.

Could an alternative be to call them Unparsed and Parsed instead of Input and Output? Then you have:

func parse(_ input: inout Unparsed) -> Parsed { ... }

func print(_ input: Parsed, into output: inout Unparsed) { ... }

Main downside is that "parse" is all over the place, but that would kinda be the case with the ParserOutput/Input typealiases anyway.

[stephencelis]

@randomeizer Interesting! Those names are definitely worth thinking about.

You may have already noticed, but to provide context for anyone reading, we recently refactored the printing branch to not have a Printer protocol at all. It's now just a ParserPrinter protocol that inherits from Parser:

protocol ParserPrinter: Parser {
  func print(_ output: Output, into input: inout Input) throws 
}

We originally had aspirations for making the parsing and printing bits of the library completely self-contained, and potentially even ship the parsing bits in one module, the printing bits in its own module with no dependencies on parsing, and then finally ship the parser-printer bits in a module that depends on both and glues them together.

The closer we get to release though, and especially with the introduction/inversion of prepend-based printers, we think that the "printer" aspect of our library is really not a self-contained unit, but rather a layer on top of parsing that undoes it.

I know @haikusw found the Input and Output naming confusing in the episodes, where we simply have a Printer protocol with no direct relation to Parser, but I'm curious if the naming clicks more now that we have this hierarchy, where every ParserPrinter is also a Parser, and to "print" simply means to turn an output back into an input:

• A parser incrementally parses some output from (usually the beginning of) some input
• A parser-printer is a parser that can also incrementally print some output back to *usually the beginning of) some **input

We definitely don't think introducing different names for these associated types is appropriate anymore, and thought Input and Output worked OK in this hierarchy if you squint a lil, but I think Parsed and Unparsed are worthy replacements. We'll discuss!

[randomeizer]

I hadn't spotted that change actually, been working on other projects this week.

It's probably a reasonable change, since it's not exactly printing in a conventional sense any more. Maybe "print" is the wrong verb now. Maybe it should be "unparse", or "flatten", or something along those lines.

Not sure what the ParserPrinter gets renamed to though, in that case. BidirectionalParser? UnParser? Meh...

For the record, not that big a deal personally, just thought I'd pass on the thought since it occurred.

[stephencelis]

It's a good thought, thanks for sharing!

One issue with changing the name from "printer" is that "parser-printer" is more of a term of art. I think it's tough to approach this topic without the burden of how much time we've spent with it, but if we can reframe our minds to think of a parser-printer's "printing" as the inverse of "parsing," and avoid the burden of "printer" being its own concept, hopefully things make a bit more sense now?

[haikusw]

I’ve also been on other things and am behind by one or two episodes now (sorry). I think part of my feedback was around: are you doing academic work here or making something to be used by non-academics? If the former, sticking with the names used in the academic papers seems good. If the latter, pick names that make sense to people who are building software and haven’t read the papers (and likely won’t). The layering sounds like a useful way to go. Unparse 🤔 Looking forward to having time to play with parsing again. cheers

…

Sent from my phone

On Mar 22, 2022, at 8:46 AM, Stephen Celis ***@***.***> wrote:  It's a good thought, thanks for sharing! One issue with changing the name from "printer" is that "parser-printer" is more of a term of art. I think it's tough to approach this topic without the burden of how much time we've spent with it, but if we can reframe our minds to think of a parser-printer's "printing" as the inverse of "parsing," and avoid the burden of "printer" being its own concept, hopefully things make a bit more sense now? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.