---
title: T-spec meeting 2023-12-14
tags: ["T-spec", "meeting", "minutes"]
date: 2023-12-14
discussion: https://rust-lang.zulipchat.com/#narrow/stream/399173-t-spec/topic/Meeting.202023-12-14
url: https://hackmd.io/RfweL7vtQ-WPy8xBc4b-kw
---

Attendees: Joel, Felix, Mara, Pietro, TC, Connor, Laurenz (Typst), carbotaniuman, tom, Lokathor, Maio

## (Pietro) Ferrous contribution

Pietro: If the spec is based on the Ferrocene spec, then Ferrous Systems can provide 2.5 days/week of work on the specification. We made a big investment to create the FLS, so it wouldn't make sense to invest to write it again from scratch.

Pietro: This is the best I was able to negotiate.

Joel: This includes anything having to do with the specification?

Pietro: Yes, it'd be the same as with Joel, e.g. Any specification work.

## Sample chapter

Mara: We should write a sample chapter from scratch. Then we could see whether what we end up with and whether it ends up close to the FLS or far away.

pnkfelix: +1. We just want to give ourselves the freedom to deviate.

Mara: We're just talking about a week or two of work here.

Pietro: Agree. We should be clear about the goals that we want to have. Probably writing a sample chapter is the easiest way to iterate on that.

Joel: We may find that lots of the FLS content makes sense, but it may make sense to deviate on tooling.

Pietro: We're not particular on the tooling. We're happy to migrate to other tooling for FLS.

Joel: {Asking clarification on the condition on Ferrous' contribution.}

Mara: If we start from scratch then it could be years until Ferrocene could use our spec. That's probably why it would or wouldn't make sense for them to put time in.

pnkfelix: Yes, it's a kind of reciprocity.

pnkfelix: We're hoping that in the middle of January we'd have something to look at.

Joel: That sounds right.

Mara: Both Joel and I were planning to independently write something and then compare drafts.

Mara: In the tooling conversation last week, it was difficult to judge what we might need because we haven't written even a single line yet.

pnkfelix: Are you planning to write separately about the same content or different content. There's value in writing on the same thing.

Joel: +1.

Mara: I mostly agree, but if one of us has more motivation for some thing, then it might make sense to diverge.

Joel: Mara, you pick the topic

Pietro: Perhaps they could be different parts of the same broad topic.

pnkfelix: I trust Mara and Joel to pick something to discuss.

Joel: We'll get somewhere within the same domain.

pnkfelix: Eric shared a list of specs. Have we reviewed it? I prefer reading these as PDFs, and I wasn't able to convert them all that way.

pnkfelix: Racket has an interesting design. They frontload the interesting content and backload the lexical details. We might also look at the ML specs.

Mara: I'm very familiar with the C++ and C specs, and somewhat familiar with the D spec.

Joel: I'm familiar with the C# spec.

pnkfelix: I'm familiar with the Java one.

Joel: Back when Sun was going to standardize Java, things happened, and MS was probably inspired by the Java approach with C#.

TC: I'd recommend people have a look at the Scheme specs, e.g. R7RS. They might be a good model.

https://small.r7rs.org/attachment/r7rs.pdf

pnkfelix: Agreed. That one wasn't on the list, but I had thought about adding it as well.

---

Mara: I'd prefer we not add too many requirements for the sample chapter on us from this meeting. It'd be better if we had some freedom. But we're open to ideas about what to write about or things to take into account.

pnkfelix: Slices and arrays may be interesting, because covering both the static and dynamic semantics may be good.

Mara: Having something that touches on syntax is where I'm thinking. E.g. functions or something.

pnkfelix: That's true of slices and arrays also.

Connor: It makes sense to colocate the syntax and semantics for that sort of thing. That's how C++ does it.

Mara: I'm interested in how we handle the formal vs informal parts of the specification. Notes on thoughts behind design decisions, etc.

pnkfelix: There are "annotated" specifications. We could take inspiration from those.

pietro: Ada for example has an annotated reference manual.

Mara: Do we want to pick a complicated topic or an easy one. Try out doing research, or just trying out presentation/writing?

pnkfelix: Easy is probably better given the timeline.

Joel: That's my thought as well. But on the other hand, a more complicated topic would help in terms of exercising the various "features" of the spec.

pnkfelix: Maybe we could do both. We could do an easy one and an hard one. It's fine if the hard one is less polished.

Connor: ...

TC: The correctness may not actually matter here. We could accept this as semi-fictional. We just want to know what it would look like if it *were* correct.

Mara: That was my question, do we only try out the writing/presentation (so correctness is not important), or do we try out researching as well (so we try to make things correct and complete)? Maybe researching is too much for now.

pnkfelix: +1. Most of our questions would be answered by something fictional.

Joel: We could do both. We could write it semi-fictionally, then do correctness as a separate step.

Pietro: ...

Mara: We should make sure to try out how things work when parts of the spec are incomplete. It's important to see what that looks like. So we could pick a big topic and stop at some point.

TC: Does this get into the question of how Ferrocene might be able to use it? They're going to need something that's complete enough for their purposes.

Mara: So next step is for Joel and me to go through the topics and pick something.

Connor: I'd be interested in writing a sample chapter also.

pnkfelix: If Mara and Joel you could broadcast your topic, then others could join in.

## Typst

TC: Laurenz, perhaps you could just give us an overview of Typst and how it could be used for this sort of thing.

Laurenz: We started building Typst in Rust some years ago because of frustration with LaTeX. In Markdown, you can be somewhat limited because it's difficult or impossible to express custom styling for various elements. Typst allows defining custom markup elements, and allows writing plugins in Rust.

Laurenz: The big question is how much and how soon HTML output would be necessary for this group. We output to PDF for now, but HTML output planned. It won't be ready in 3 months. Hopefully in 6 months.

TC: How much and how soon do we need HTML output?

pnkfelix: It is important. Hopefully, though, toward the start, our source will be relatively simple. If we start with Markdown, then we could always convert to Typst later.

Mara: Joel and I agree on starting with the simplest thing possible, then see what limitations we run into.

Connor: One thing that may be important is to have a rendered copy side by side with your source format. Markdown has that.

pnkfelix: Typst has that also with their web app.

Laurenz: We have the website with instant preview, and there is a VSCode extension with instant preview and auto complete. These all work well in my experience.

TC: To what degree are we expecting to hit the limitations of Markdown in terms of element styling?

Mara: We'll only know that once we write something.

pnkfelix: Markdown can be constraining.

pnkfelix: Laurenz, are you familiar with the system that Racket uses? They have a domain-specific language for writing their docs. It's powerful. It integrates with their editor. It's called Scribble. I don't think Scribble is what we want. But I was inspired by it. I'm inspired by lots of things in Scheme.

TC: Perhaps we should open a thread on Zulip about the sample chapter. Then people can follow along on the topic chosen.

Joel: +1.

## Next meeting

Joel: Do we want to meet next week and for the rest of the year?

all: We can discuss this on Zulip.

(The meeting ended here.)