This is where the Slangify approach becomes more valuable than plain prompting. Constraints live in the grammar and the Booking class — not in the prompt.
Restrict party to one or two digits (no absurdly large parties):
token party { <[1..9]> \d? } # 1–99
Restrict time to valid 24-hour ranges:
token time { <[0..2]>\d ':' <[0..5]>\d }
Any LLM output that violates these rules causes the grammar to fail — the error surfaces before the result reaches your application.
Use Raku’s type system and TWEAK for business-rule validation:
class Booking does Actionable {
has Str $.name;
has Int $.party where 1 <= * <= 20; # range constraint
has Str $.time;
has Str $.restaurant;
has Str $.date;
}
If the LLM produces party: 0 or party: 99, object construction fails with a clear type error rather than silently accepting bad data.
# LLM normalized "a crowd" to: party many
my $m = Slangify::Tutorial::Grammar.parse(
'name "X" party many time 19:00 restaurant "Y" date today'
);
say $m.so; # False — grammar rejects non-numeric party
Readers love seeing failure and correction. The grammar gives you both: a clear rejection plus a single place to tighten the rule.
Use \d+ in the token and Int in the class attribute.
Use alternation in the token: low | medium | high.
Use a specific pattern token rather than bare \S+ if you need validation.
Keep \S+ or <-["]>+ but add Str typing so at least the attribute is defined.