uCalc API Version: 5.7.0-preview.1 Released: 7/30/2026
Warning
uCalc API Preview Release Notice:This preview documentation describes the intended behavior of the API. It is not fully accurate or complete.The current preview build contains incomplete features, unoptimized performance, and is subject to breaking changes.Use of the preview version in your production code is not recommended.
Product:
Explains the fundamental differences between uCalc's token-aware Transformer and traditional character-based Regular Expressions.
Regular Expressions (Regex) are an indispensable tool for pattern matching in raw, unstructured text. However, when working with structured or semi-structured data—such as source code, configuration files, or markup languages like HTML and XML—their character-based nature reveals significant limitations that can lead to fragile and unsafe code.
uCalc's Transformer offers a fundamentally different, token-based approach that is safer, more readable, and more powerful for these tasks. This topic explores the key distinctions.
This is the single most important concept to understand:
This structural awareness prevents the most common and dangerous bugs associated with using regex for code manipulation.
Imagine you want to rename the variable rate to annual_rate in this line of code:
csharp
rate = 0.05; // Current rate
print("The rate is: " + rate);
A simple regex find-and-replace for the word \brate\b would incorrectly change it everywhere, including inside the comment and the string literal, corrupting your code and output.
The uCalc Solution
Because the uCalc Transformer tokenizes the text first, it knows that "The rate is: " is a single, atomic string token and // Current rate is a whitespace token (provided you have defined it as such). By default, a rule to replace the identifier rate will not even look inside them, ensuring a safe and correct transformation.
csharp
annual_rate = 0.05; // Current rate
print("The rate is: " + annual_rate);
This safety-by-default is a core architectural advantage.
| Feature | Regular Expressions | uCalc Transformer |
|---|---|---|
| Core Unit | Character | Token (word, number, symbol) |
| Safety | 🔴 Unsafe for code; can corrupt string literals and comments. | 🟢 Safe by default; respects structural boundaries (QuoteSensitive, BracketSensitive). |
| Readability | 🔴 Often cryptic (e.g., (?<=\s)\d+). Difficult to maintain. | 🟢 Readable (e.g., {@Number}). Self-documenting patterns. |
| Nested Data | 🔴 Fails on recursive structures like balanced parentheses. | 🟢 Natively handles nesting and recursion. |
| Extensibility | 🔴 Fixed syntax (\d, \w). | 🟢 Dynamic syntax. Define new token types at runtime via Tokens.Add(). |
| Backreferences | 🔴 Numeric ($1, \1). Prone to indexing errors. | 🟢 Named ({myVar}). More readable and robust. |
Despite the uCalc Transformer's advantages for structured data, regular expressions remain the superior tool for low-level, character-based pattern matching in unstructured text. uCalc acknowledges this by allowing you to embed raw regex directly inside a pattern when you need that level of control.
csharp
// Match a variable that must be exactly three uppercase letters.
t.FromTo("{code:'[A-Z]{3}'}", "...");
This hybrid approach gives you the best of both worlds: the high-level structural awareness of the uCalc Transformer and the low-level precision of regex when you need it.
Choose the right tool for the job. For searching arbitrary character streams, use regex. For safely and reliably parsing or transforming code, configuration, or any other structured data, uCalc's token-aware Transformer is the superior choice.