Classes consist of a name, a list of properties, and their types. In the context of LLMs, classes describe the type of the variables you can inject into prompts and extract out from the response.

Note properties have no :

1class Foo {
2 property1 string
3 property2 int?
4 property3 Bar[]
5 property4 MyEnum
6}

Class Attributes

@@dynamic

If set, will allow you to add fields to the class dynamically at runtime (in your python/ts/etc code). See dynamic classes for more information.

BAML
1class MyClass {
2 property1 string
3 property2 int?
4
5 @@dynamic // allows me to later propert3 float[] at runtime
6}

Field Attributes

When prompt engineering, you can also alias values and add descriptions.

@alias
string

Aliasing renames the field for the llm to potentially “understand” your value better, while keeping the original name in your code, so you don’t need to change your downstream code everytime.

This will also be used for parsing the output of the LLM back into the original object.

@description
string

This adds some additional context to the field in the prompt.

BAML
1class MyClass {
2 property1 string @alias("name") @description("The name of the object")
3 age int? @description("The age of the object")
4}

Constraints

Classes may have any number of properties. Property names must follow these rules:

  • Must start with a letter
  • Must contain only letters, numbers, and underscores
  • Must be unique within the class
  • classes cannot be self-referential (cannot have a property of the same type as the class itself)

The type of a property can be any supported type

Default values

  • Not yet supported. For optional properties, the default value is None in python.

Inheritance

Never supported. Like rust, we take the stance that composition is better than inheritance.