T-spec meeting 2024-04-25

--- title: T-spec meeting 2024-04-25 tags: ["T-spec", "meeting", "minutes"] date: 2024-04-25 discussion: https://rust-lang.zulipchat.com/#narrow/stream/399173-t-spec/topic/Meeting.202024-04-25 url: https://hackmd.io/IgmkLP2YQbyCgTkGAaKHTg --- Attendees: Joel Marcey (needs to leave at 50 after), Eric Huss, TC, Pierre-Emmanuel Patry, Connor Horman, Mario Carneiro, Monadic Cat, pnkfelix Potential Agenda: * 2024 Goal + Milestones (discuss and try to provide to @nikomatsakis) * Can we merge [Lexing chapter](https://mjw.woodcraft.me.uk/2024-lexeywan/) as official? * [Using Minirust and other DSLs as normative](https://github.com/orgs/rust-lang/projects/45/views/9?pane=issue&itemId=60402261) ## Normative DSLs Joint meeting with t-opsem to discuss there. *Connor to coordinate the date and time for the meeting.* Connor: Connor, t-spec team (Joel, Mara at the least), t-opsem (Ralf at least, but potentially three members) Mario: Meeting to go over the proposed content of the specification. Given that structure, what does the dynamic semantics look like. ## 2024 Goal(s) / Milestones Joel: Niko asked whether we want to create project goal here. We probably want to create a single one for the spec. We probably won't have done for 2024 all of what we had hoped, e.g. a spec that people could use in certification processes. pnkfelix: Even if we say we have a v0.1 version of the spec, that doesn't necessarily imply any particular scope. So it'd be useful to think what the minimum useful product would be. Maybe we could have a goal about having a partial spec that would allow understanding a subset of the language. pnkfelix: One of the goals for the spec is to better allow the project to iterate on the language. Maybe we could focus on that. Joel: As a goal, I was thinking that by the end of 2024, we could have *some content* for every subject we want to discuss. Mario: If we're thinking about the fastest way to get to value, we could think about individual cases, e.g. match exhaustiveness comes to mind given the recent work there. Mario: That is, we could ask, "what vertical goals could we have?" Connor: Agrees with the general principle - how complete the parts we have written. Not necessarily a use case, but pick something to specify and go for that. Mario: We might want to have some parallelism here. pnkfelix: I'd echo Connor's point that a goal should be framed that we should have a small set of chapters that are complete and not a lot of chapters that aren't complete. We don't want to go wide and not deep, as that's one of the concerns we had with the FLS that caused us to not adopt that. Eric: The project goals have owners. Who would be the owner here? (Discussion about this.) TC: The owner is the person who accepts the moral weight of ensuring the value promised by the goal is delivered. The goals are a contract between the teams and the owner. The teams are committing attention and other resources. The owner is responsible for ensuring that commitment of resources is worth it. Connor: Perhaps the right goal is having specific chapters stamped by the teams that are owners/experts of those chapters. pnkfelix: I like the spirit of this, but I'm concerned that we might tie our hands with this and end up with a result with which we're not happy. The important thing for this year may be to show that we're able to work within the project to make progress. That is, that we have a process for working with the various teams. pnkfelix: I agree with a goal that we should have a certain number of chapters that are deemed complete both by us and by the relevant teams, but perhaps we should not say what those chapters are exactly. We could pick K out of N objectives. But there's of course a risk that we could pick the easiest K and not deliver the value for which people were hoping. Joel: Perhaps we should go down the flow chart of how a program is written. That's at least another way we could approach this. Mario: We might want to order is something closer to difficulty order. We might actually *want* to pick the easiest K out of N. This would help in proving out the process, as pnkfelix mentioned. Conner: The easiest K will be subjective. It may depend on who is coming along to write it. This is turned on its head for the top-level chapters. The difficulty is strictly increasing, probably quadratically. pnkfelix: This is another reason pick K of N is good, as then we can pick the K based on what resources are available. Joel: Whatever content we deliver, if we haven't figured out how to get content reviewed and approved by the teams by the end of the year, then there will have been a failing here. ## Merging Lexing pnkfelix: On the one hand we could merge this today. On the other, it might sent a precedent that we don't want, e.g. on stylistic points. TC: Eric, to what degree could this work be merged into the Reference today? Eric: This is what Matthew is working on. The lexing section in the Reference needs work, and this will clean it up. On the other hand, we could merge this sort of thing into the spec and start to deprecate the Reference. This needs more discussion. (The meeting ended here.)