Hi @aaronv (BAML) I willing to take this up.

sure, first read the notion doc, and create a new doc of your own with the same sort of design -- how do we render each type in TOON format, and then we can approve it

okay, I will begin work on this

I have a question: as far as I can understand, toon doesn't support comments, so any @ description annotations in BAML would (currently) be ignored during conversion form BAML code to toon, correct? I've opened an issue on the toon spec repo to address this, and hopefully someone comes up with some syntax in toon to allow inline comments. In the implementation, it would be good to leave a hook for taking in @ description annotations from BAML during conversion. Just so that it can be extended in due course 😅

we wouldnt serialize any

class

as TOON in the prompt, only support parsing toon outputs. And yes we would probably ignore descriptions (unless someone has ideas)

this is what I hit just now when writing notion doc. lol

probably requires some research into the toon github repo to see how others are thinking about this, seems like a super common problem

Yea. So, for now, we can only parse the toon outputs, and not serialise baml classes into toon (no

class

, no

description

support)

or an alternative is to render the schema as usual, but add custom instructions to show the actual format we expect. Not sure how performant that would be, or whether it would confuse the model (e.g. why did you show me a json schema and a toon format instruction?)

if LLMs understand 'toon' without explaining much, we can adjust spec to our liking. We just want to save tokens, right?

i think there's two things the design doc needs: 1. saving tokens serializing classes into baml prompts 2. saving tokens on the outputs (which is what we can tackle first)

i suspect json schema + toon would be cognitive overhead for the model. not worth it.

that doc for xml has most of the corner cases IIRC

Ditch toon? https://x.com/vaibcode/status/1989419713697648696

it doesn't mean we can't implement it. Users can choose depending on how complex their schemas are. Most of the gains are with arrays of objects

I dunno, this does seem very contradictory for the model and it would make sense if this confused smaller models rather than helps them. Seems like a lot of work for a format that supports something very basic. I'm with Vaibhav on this one 😬

+1

we did end up implementing TOON btw, will come out on the next release, but only for serializing objects in prompts using jinja, not for actually generating TOON using llms. Vaibhav will share his thoughts on twitter on what made him change his mind

Ok! Looking forward to it! Is there a snippet you could share on how the serialized objects look that came from Jinja?

Still not 💯 % sure that it works well in practice tbh 😅

Interesting. What changed ?