Is there a way to unwrap_list and know the inner wasm:component:types:Type associated with it with the inner handle? I'm running into this scenario trying to map some things with lists of lists (nested lists)? I'm probably missing something. I didn't find a good test w/ inner lists and wit as well.
good q, the only test i can find that uses list<list<string>> is in wit-bindgen
https://github.com/bytecodealliance/wit-bindgen/blob/main/tests/runtime/lists/wasm.rs#L100
when using wit-bindgen, we present the list as a Vec<Vec<String>>, so the api definitely works. you can use cargo expand
to see how the wasmtime::component::binden! macro generates the code that goes from component::Val to that
does that answer your question? or is there something particular about the types representation of lists that is missing here
it looks to me like if you have a ty: Type
and its a list, the elem type is then ty.unwrap_list().ty()
Thanks @Pat Hickey. I'll double check the bindgen. I was using ty.unwrap_list().ty()
while trying to reuse the echo component stuff in the wasmtime repo test suite. It was just giving me the inner list handler at index 0 (first run returns 1). But, I think I maybe got it. :)
@Pat Hickey a Q in addition then. In the current wit / component spec, would there be any way to encode heterogeneous lists? Or is that eve something to think about :)
theres no dynamic types in component model, so youd need to make an enum of the possible variants in your hlist
theres also no recursive types
these do eliminate some cool possibilities, but theyre reasonable restrictions for a lot of "real world" programs for now, and make it a lot more tractable to ship this thing :)
Yep, figured @Pat Hickey. I'm writing an IR from something that had recursive types and mapping that, with runtime checking, to wasmtime:component Vals. Encoding the enum of variants is next on my list.
Thanks again @Pat Hickey
Last updated: Dec 23 2024 at 12:05 UTC