Parsing GrammarRules Locally

Cloud test name	Pattern shape	Result
TestGrammar_1	"hello"->"greeting"	literal string match
TestGrammar_2	FixedOrder ["add",a: GrammarToken ["SemanticNumber"],"and",b: GrammarToken ["SemanticNumber"]]:>a+b	named slot with type via GrammarToken
TestGrammar_3	`FixedOrder["turn", OptionalElement["the"], appl:("stove"	"oven"
TestGrammar_4	`nums:DelimitedSequence[GrammarToken["SemanticNumber"], ","	"and"] :> Total[nums]`
TestGrammar_5	GrammarRules[{rules},{defs}] with subsidiary "MyCity"->... definitions	named-domain definitions
TestGrammar_6	c:GrammarToken["City"] resolving to an Entity["City",...]	Interpreter-backed semantic tokens
TestGrammar_8	AnyOrder["red","green","blue"]:>"all three colors named"	permutation matching
TestGrammar_10loose	AllowLooseGrammar->True (default)	matches inside arbitrary surrounding text
TestGrammar_12	CaseSensitive["Hello"]->...	per-rule case sensitivity

The pattern shapes accepted, as documented in

GrammarRules

"string" literal string
StringExpression[...] arbitrary string pattern
RegularExpression[...] regular expression
form1 | form2 | ... alternative forms
OptionalElement[form, def] optional form, with default
FixedOrder[form1, form2, ...] forms in a fixed order
AnyOrder[form1, form2, ...] forms in any order
form.. repeated
DelimitedSequence[form, sep] form repeated with delimiters
GrammarToken["name"] built-in or defined domain
CaseSensitive[form] case-sensitive match
x : form named binding

Built-in

GrammarToken

types that resolved in cloud tests (more exist):

◼

"SemanticNumber"

("six" → 6)

◼

"Number"

"Integer"

"Real"

(digit-based)

◼

"Percent"

(

"5"

→

Quantity[5,"Percent"]

)

◼

"City"

"Country"

(Interpreter-backed)

◼

"Color"

"Date"

"Time"

"DateString"

◼

"MathExpression"

(

"1+1"

→

)

Part 2 - What
Wolfram`Parser`
supports locally today

Parse[GrammarRules[{...}],input]

accepts two surface shapes for the rule LHS, both lowered on the same code path:

(a) The string-template form

The simpler shape (which the cloud's built-in does not accept, but

Interpreter

["..."]

and

FormFunction

do): a string with

<name:Type>

slots, like

"add <a:Number> and <b:Number>"

. Each template is split into literal segments and slot recognizers, sequenced into a

ParseSequence

, and the slot bindings flow into the rule body via

ReplaceAll

on the named symbols.

Slot types supported:

<name:Type>	Recognizer	Result form
<name> (bare)	ParseSome[ParseCharacter[WordCharacter]]	String
<name:Word>	ParseSome[ParseCharacter[LetterCharacter]]	String
<name:Number>	ParseSome[ParseCharacter[DigitCharacter]] + FromDigits	Integer
<name:Integer>	alias for Number	Integer
any other type	ParseFail (use the pattern form for semantic types)	-

Bare slot captures a word run:

In[1]:=

Parse

[GrammarRules[{"the weather in <city>"city}],"the weather in NYC"]

Out[1]=

NYC

Typed slots and arithmetic in the rule body:

In[2]:=

Parse

[GrammarRules[{"add <a:Number> and <b:Number>"a+b}],"add 3 and 5"]

Out[2]=

Multi-slot template with a list-shaped result:

In[3]:=

Parse

[GrammarRules[{"<verb:Word> <obj:Word>"{verb,obj}}],"eat sushi"]

Out[3]=

{eat,sushi}

(b) The pattern form (matches the built-in's surface syntax)

The same shapes the cloud-deployed

GrammarRules

accepts -

FixedOrder

Alternatives

(

form1|form2

OptionalElement

DelimitedSequence

Repeated

(

form..

CaseSensitive

GrammarToken["Name"]

, and the

x:form

capture form (

Pattern[name,form]

). The same

GrammarRules[...]

expression you would

CloudDeploy

runs locally without modification.

Each pattern node lowers to a

ParserCombinator

; the captures collected by

Pattern[name,_]

nodes bubble up as an

Association

of bindings, which then substitute into the rule body via the same

ReplaceAll

machinery the template form uses.

	Built-in pattern node	Lowered to
	"string"	ParseLiteral
	form1\|form2\|...	ParseChoice
	FixedOrder[f1,f2,...]	ParseSequence with optional whitespace between elements
	AnyOrder[f1,f2,...]	ParseChoice over every permutation of the FixedOrder lowering (N! alternatives)
	OptionalElement[form]	ParseChoice[form,ParseSucceed[Missing["NoMatch"]]]
	OptionalElement[form,default]	ParseChoice[form,ParseSucceed[default]]
	form.. ( Repeated )	ParseSome
	form... ( RepeatedNull )	ParseMany
	DelimitedSequence[form,sep]	ParseSepBy1
	CaseSensitive[form]	inner form (case-insensitive matching not modeled)
	RegularExpression["r"]	ParseRegex (anchored regex match at the current position)
	GrammarToken["Number"]	the local slotParser["Number"] (digit-based, no Interpreter call)
	GrammarToken["Word"]	the local slotParser["Word"] (letter-based)
	GrammarToken["Integer"]	alias for Number
	GrammarToken[<other-string>]	a word-ish run fed to Interpreter[type] ; parser fails when interpretation fails
	Pattern[name,form] ( x:form )	inner form, with name->matchedValue added to bindings

FixedOrder

with two typed slots, arithmetic in the body:

In[4]:=

Parse

[GrammarRules[{FixedOrder["add",a:GrammarToken["Number"],"and",b:GrammarToken["Number"]]a+b}],"add 3 and 5"]

Out[4]=

Alternatives

with a captured choice:

In[5]:=

Parse

[GrammarRules[{appl:("stove"|"oven"|"fridge")appl}],"fridge"]

Out[5]=

fridge

DelimitedSequence

collecting a list of numbers:

In[6]:=

Parse

[GrammarRules[{nums:DelimitedSequence[GrammarToken["Number"],","]Total[nums]}],"1,2,3,4"]

Out[6]=

OptionalElement

with a default:

In[7]:=

Parse

[GrammarRules[{FixedOrder["turn",OptionalElement["the","no-the"],appl:("stove"|"oven")]appl}],"turn stove"]

Out[7]=

stove

AnyOrder

matching any permutation of three literals:

In[8]:=

Parse

[GrammarRules[{AnyOrder["red","green","blue"]"all three"}],"blue red green"]

Out[8]=

all three

RegularExpression

as a slot:

In[9]:=

Parse

[GrammarRules[{n:RegularExpression["\\d+"]ToExpression[n]}],"42"]

Out[9]=

Subsidiary-domain definitions via the two-argument

GrammarRules[rules,defs]

In[10]:=

Parse

[GrammarRules[{FixedOrder["from",c:GrammarToken["MyCity"]]c},{"MyCity"("Paris"|"Tokyo"|"Boston")}],"from Paris"]

Wolfram Language Paclet Repository

Parsing GrammarRules Locally

What this note covers

Part 1 - What the built-in supports

Part 2 - What
Wolfram`Parser`
supports locally today

(a) The string-template form

(b) The pattern form (matches the built-in's surface syntax)

Part 3 - The gap

Caveats on the Interpreter-backed slots

Part 4 - When to use which

Parsing GrammarRules Locally

What this note covers

Part 1 - What the built-in supports

Part 2 - What Wolfram`Parser` supports locally today

(a) The string-template form

(b) The pattern form (matches the built-in's surface syntax)

Part 3 - The gap

Caveats on the Interpreter-backed slots

Part 4 - When to use which

Part 2 - What
Wolfram`Parser`
supports locally today