[Link to current grammar](https://hackmd.io/-f_hHLrTTqm_AuKHJ70zJA)

# July 27

* Agenda [ Feel free to add topic ]
* Brian giving a walkthrough of the current prototype status

* Notes
*

# July 20

* Agenda [ Feel free to add topic ]
* Brian's updates
* Overall making progress on integrating into WIT resolution. No pressing questions just very tedious to grok all the nuance regarding how worlds and interfaces are resolved and what can be skipped. I have a meeting with Alex after this to backfill some context that has been hard to extrapolate from the code.
* General discussion on resolving "component imports" (e.g. `use wasi:http`) at the level of WIT.
* After next week, i'll be taking off a few weeks until late August to move and to attend the Fermyon offsite in Oslo. Do you all want me to cancel this meeting until then (the week of the 25th)?
* [insert topic here]

* Notes
* Peter: Let's keep this meeting going while Brian is out and folks can chime in with topics
* Peter: no time to work on wasmcompose. overhauling cargo component. hoping to land that work soon. fully supported resources when Joel is done in cargo component which is cool. Cargo component changes will have some real potential benefits.
* Brian: on cargo component, do you anticipate needing a compose subcommand on cargo component.
* Peter: yes for local testing. deps on interfaces, etc before running through test host
* testing relies on good compose story
* Trevor: only thing on branch atm is the parser?
* Brian: yes. started working on resolve and now doing something different. Taking a 1 off approach to resolving component defintion in their structure and their nature. Ordering that happens for resolving worlds and interfaces but that doesn't apply to component resolution. Will be talking to Alex about if it makes sense to do a 1 off resolution for components outside of the ordering resolution logic.
* Uniqueness guarantees of item names happens in the topological ordering logic
* Trevor:
* Brian: uniqueness of the actual names of the elements, names of words, interfaces and component definitions
* Trevor: interested in understanding where problem arises when trying to do it all at once
* Brian: points at which you integrate into where those checks are being made is while the topological ordering is being built. might make sense to keep that check there around the names and then doing the rest of resolution after
* Trevor: doing reslution in separate pass makes sense and keeps the uniqueness checks all in one place makes sense
* resolving component imports
* last week we talked about taking a similar approach to deps (dir name impls) where we could resolve impls.
* when we do resolve to a wasm on disk what do we do with that? do we try to parse it? do we introduce a wasm parser dependency into the wit parser?
* path grammar
* Peter: will have to parse to some degree to get exports
* Brian: alternatively, what if we treated use wasi:http
* reusing words across packages
* Peter: don't want to end up in a wast word where you can do things that are syntactically valid but aren't actually valid and lose all span info
* Brian: would need to propogate that properly
* Danny: registries and transitive deps
* context: https://bytecodealliance.zulipchat.com/#narrow/stream/352111-warg/topic/Transitive.20Implementation.20Imports/near/376773218
* dep tree
* Peter: this parser should allow us to specifiy locations of
* Danny: trans deps and composition are independent in that neither is a pre-req of another
* wasm-tools bundle command for transitive dependency
* plan of attack atm: what the wat output would look like from composition and then i can write that by hand and then perform the dep resolve
* is it feesible to do have guest lang be written
* Peter: branch of cargo-component that could have extensions that you've worked on with luke

* peter: did luke give any indivation on PR for extending wit syntax?
* danny: last monday was the aspiration. started soliciting feedback. since he's out of office, been leaving him along. will return to this after he gets back.
* Peter: unit official, would be nice to have a branch of wasm-tools and complementary branch on cargo-compoennt and use that to move froward
* danny: currently have branch on wasm-tools with syntax and other stuff and also have one on the registry and today in line handwriting and fixing a few things
* looking to finish things today and start building large binary out of these things

# July 13

* Updates
* [Brian] Made a few tweaks to the grammar to align with whats available in WIT and finished implementing the parser. Started to model the "resolved component defintion" and integrate into resolve.
* Can component definitions be referenced across WIT packages?
* How should we resolve component imports in WIT resolution, e.g. `use wasi:http`?
* Current structure of "resolved component definition" in `lib.rs`:

        pub type ComponentId = Id<Component>;

        pub struct Instantiation {
            // The left hand side name of the instantiation.
            pub name: String,
            pub args: Vec<InstantiationArg>,
        }

        pub enum InstantiationArg {
            Interface(InterfaceId),
            Instantation(usize),
        }

        pub struct Component {
            /// The package that owns this component definition.
            pub package: Option<PackageId>, 
            /// The WIT identifier name of this component definition.
            pub name: String,
            /// Documentation associated with this component definition.
            pub docs: Docs,
            
            // imports
            // exports
            
            pub instantiations: Vec<Instantiation>,
        }

* Notes
* Brian's updates
* finished implementing the parser
* made some tweaks to grammar that reuse certain productions from the wit grammar
* biggest one was the import production, can reuse WIT world sytax
* only diff we were proposing was ID colon
* how we were doing it was introducing an ambiguity
* hoping we can talk about the snippet above, rationalize how we do resolution of the component imports (wasi:http)
* my understanding is wasi:http should point to actual component

* (Peter) in WIT parser have mechanism for doing that. Could think of something there that could help with testing this.
* (Brian) Next to deps, have an impls directory for wasms to be resolved
* (Peter) Namespace folder? wasi directory. would work for now
* (Brian): straightforward. tricky is how to hook into resolution as of today. Alex says no need to worry about topology today. In the component WIT< you can import an anonymous interface, so there is some part of it that needs to update the interface arenas. Maybe this isn't a big deal? Maybe this could be a duplication?
* (Peter): Bogged down with cargo component changes. Once this is wrapped up, will focus on wasm compose to do whatever we need to resolve id, instantiation
* (Brian): been following resources, cargo component plan looks awesome
* (Brian): does it make sense to dump AST into this top level component shape?
* Nods from Peter. Makes sense.
* (Brian): Once implementation piece is in, next could be WIT.md proposal with these changes.
* (Peter): By then, we can coordinate hand over so Peter can drive.
* (Brian): PR to parser and feature gate
* (Trevor): Where is this work happening?
* (Brian): Fork of wasm-tools

# July 6

* Updates
* [Brian] Have most of the `component { ... }` syntax implemented in `wit-parser` (not yet resolving); I'm a little unsure about the "component import" syntax being `use` now that we are integrating into `WIT`; it feels weird to effectively overload `use` to mean "component import" when used inside `component { ... }` vs. its typical semantics to share types today.

* Open questions
* How should `component { ... }` entities in `WIT` be represented in a Wasm-encoded `WIT` package?

* Work to be done
* PR update to `WIT.md` with `component { ... }` syntax
* Implementation imports (seems parallelizable)