T-spec meeting 2024-03-07

--- title: T-spec meeting 2024-03-07 tags: ["T-spec", "meeting", "minutes"] date: 2024-03-07 discussion: https://rust-lang.zulipchat.com/#narrow/stream/399173-t-spec/topic/Meeting.202024-03-07 url: https://hackmd.io/hMSeVu9kQ2myAiQGM9JP6w --- Attendees: Joel Marcey, Mondiac Cat, Eric Huss, Mario Carneiro, Lukas Wirth, Connor Horman, TC, Pietro, pnkfelix Potential Agenda: * Representation and Validity Discussion * GitHub Issue Triage * Chapter Selection and Status ## Representation and Validity [Context](https://rust-lang.zulipchat.com/#narrow/stream/399173-t-spec/topic/representation.20and.20validity) Connor: Ralf wants layout separate from representation Mario: Also a disagreement about the use of the word "representation". The use here is not the same as used in the opsem discussions Connor: Used the definition in the discussion so that could use the definition of type like did Mario: opsem is going to be using minirust for this whole portion of the spec. Why isn't the prose version of the spec just using word for word minirust. Connor: The wording doesn't need to be the same, just the meaning. But it needs to be adaptable. Mario: minirust doesn't have a spec per se, but it does have structure. There should be a 1:1 correspondence with the spec and what minirust says. Felix: How do we validate against minirust if we structure the content differently than how minirust describes it. Felix: It is a good goal that minirust and the spec are consistent. Connor: Manual validation? Joel: That seems like a tough thing to do, possibly error prone. Connor: Doesn't want to import SpecR Mario: Most of the non-code minirust text is not normative. Connor: doesn't think 1:1 correspondence is possible. Felix: Impossible or not ideal? Mario: It may be ok to have similar, duplicative information to the reader, for example on size Joel: minirust is the default and we modify the spec as necessary Mario: Can go both ways Felix: A in minirust corresponds to A in the spec, 1:1, but it could also be A corresponding to A, B, C in the spec sometimes, 1:many Mario: we should make it possible to have mostly a 1:1 mapping Connor: 1 minirust concept should be covered by 1 chapter. Not necessarily a clause to line relation, but chapter to struct. Mario: Can we prototype this? Compromise a literal translation of minirust to what can be a spec. Joel: What is the downside of just going Connor's route? Mario: Folks working on minirust will probably end up being unhappy. Want to get to a place where everyone is happy Joel: Where do we go from here? Mario: We start with an enumeration, for each thing we say about all values, one for each of them, text for each one of those cases, and then done. Joel: Will there be a jarring difference between writing the spec the "minirust" way vs. other areas of the spec that may not be written that way? Mario: We don't need to write the spec as code Felix: WHy not start on text about values first? Why is that not a natural place to start? Connor: Working based on time to take to complete. Value type could be months of work Mario: Not convinced it will be months. Could be a day. Especially if you utilize what already exists in minirust. Connor: Have background knowledge on layout and representation. Mario: We want representations for every value. Connor: Just assume the minirust definition. Mondiac Cat: [Minirust values definition](https://github.com/minirust/minirust/blob/master/spec/lang/values.md) Felix: Me, Joel, and potentially Mara can work on this ## GitHub Issue Triage [Issues to discuss](https://github.com/rust-lang/spec/issues?q=is%3Aopen+is%3Aissue+label%3A%22t-spec+meeting+discussion%22) ### Markdown Style Guideline [Issue](https://github.com/rust-lang/spec/issues/40) Connor: End of lines? Eric: Use backslash to represent end of line. TC: The "one sentence per line" style proposed is difficult for me to read, personally. I always have to read the rendered version when the source is in this style. And since sentences can still be long, I still need to turn on wrapping in my editor, and the result of that is very unpleasant. This style feels like a workaround for poor tooling in the days before highlighted word diffs and highlighted side-by-side diffs. Mario: One line per phrase? Line breaking on semantically important places. Eric: Semantic linefeed is fine. Joel: Linter for this or manual enforcement. Eric: Can modify reference linter for this. Mario: Phrase-based semantic line feeds look a bit like poetry. TC: As with poetry, that can make it difficult to enforce a consistent style. There seem to be three options: semantic (and/or phrase-based) line feeds, hard wrapping (e.g. at 80 characters), or soft wrapping (i.e. line per paragraph). Pietro: Ferrocene wraps on 80 chars, but is not strictly enforced. Lukas: Doesn't prefer wrapping at 80. Likes one sentence per line Felix: In terms of workflows, I'm curious whether people spend more time reviewing rendered text, or spend more time looking at the source (which puts a strong value on the density of the text and raises the issues TC mentioned)? Connor: source and rendered side by side Joel: Same. But generally reviews source during GitHub reviews Mario: Both semantic linefeed and 80 characters Pietro: People mostly want to review the source code because of forking locally. Mario: Can you just have a rule for suggested breaks? Just do something reasonable. Felix: Can leave it up to the author, but some guidance is necessary Eric: Make a proposal not to have line wrapping like TC was suggesting. Most of spec will be short clauses. **Proposal** **No line wrapping Break on short clauses** ## Chapter Selection and Status [Chapter Outline and assignments](https://github.com/rust-lang/spec/issues/43) [Connor's chapter on Dynamic Layout](https://github.com/rust-lang/spec/pull/15) Matthew Woodcraft [offered](https://rust-lang.zulipchat.com/#narrow/stream/399173-t-spec/topic/Lexing) to help with chapter on Lexing