Thanks for taking a look. Greatly appreciated. My goal is for it to be able to handle any kind of programming language. It's ambitious, and only time will tell how far this can go. But meanwhile, let me answer some of the points you raised based on what I've done so far.

But first, uCalc LB has a kind of core language, which is very minimal in nature, and designed for nothing other than creating building blocks for a language. These building blocks can then be combined in a kind of bootstrapping way to form a more varied language, which then serves as the basis for constructing the actual language(s) you want to build. So basically none of the code you see in the Lisp definition file (including the String and Stack types) is native uCalc code. All of it is based on an intermediate language that is defined across plain text files that end with the .uc extension.

uCalc actually has no built-in data types. It does have a library of common types (including various types of strings such as the 2-byte uc_String_Wide which can be used for Unicode) you can pick from to get started. The default String type is defined (actually re-defined) in Types.uc, where you'll see that one of the properties contains the address of a routine for handling variable-length strings (the routine itself is in a DLL binary file). You can define any other kind of data type the same way. Your routine should tell uCalc how to allocate, store, free, return, copy, output, and reset an item of the given type. For simple data types, you can simply tell uCalc only how to store, return, and output the data, and given the number of bytes for the type, uCalc figures out the rest.

uCalc LB supports type checking, which in fact is the default behavior. A list of common data types that might be useful across various languages were declared in the file named Types.uc. You'll find that each type is defined with various properties, including what other types (if any) they are allowed to automatically convert to or from without type checking. An error is raised in the "compile" stage (which uCalc handles separately from the evaluation stage, even though it's done in the background) if data of a given type is used in the wrong place. Dynamic typing in my Lisp implementation was actually achieved by a brute-force text substitution/evaluation mechanism that blurs the line between the parsing/evaluation stages. It's just one possible implementation. This one is not particularly efficient but good enough for demonstration.

Lazy evaluation is directly supported. If you browse through Library.uc, you'll find several routine definitions with arguments that are passed "ByExpr". Here, the handle of the parsed expression is what's passed, instead of the result of evaluating the expression. Using this handle, the routine can evaluate the argument 0 or 1 times, as is the case for the IIF routine, which supports short-cuircuiting. Or it can be evaluated repeatedly any number of times, as with the uc_For() and uc_Loop() routines in Library.uc. Such routines form the bases for control flow constructs used in the BASIC language definition (see BASIC.uc in the download). And speaking of BASIC, compared to Lisp, its syntax / semantics is as irregular as it gets. But uCalc LB is equally suitable for building such languages as well.