cwal

WHCL - the WanderingHorse.net Command Language
Login

WHCL - the WanderingHorse.net Command Language

(⬑Central whcl Documentation Hub)

Status (2022-02-23): whcl's core-most bits are "done" and working, as are the core-most script-visible APIs. There is still refinement and documentation to do, but what's there works.


Other docs:

WHCL?

echo "Hello, world!"

WHCL, the WanderingHorse.net Command Language, is cwal's fourth programming language, a "command-centric" language strongly influenced by TCL. Since TCL is, by its advocates, pronounced "tickle," WHCL is, by its developer, pronounced "whickle." (It is probably a good thing, then, that it's not called DCL. The name PCL was avoided because it's already in use by at least two unrelated programming languages.)

WHCL has reached a usable state, considering its limited intended scope (namely, for driving unit tests for C/C++ code, not developing applications). However, it's still an experiment at this stage and may undergo any number of changes.

Though it's convenient to think of WHCL as a TCL semi-clone, some of the significant outward differences are:

cwal's s2 language has long been the centerpiece and crowning achievement of the cwal project, and cwal was designed for languages like s2 in mind. WHCL represents a completely different style of language, and certain challenges vis a vis prior cwal-based works, are already visible. None of them seem unsurmountable, though, and WHCL would be a better fit for one of cwal's original language targets: mini-languages used for driving unit testing for C/C++ libraries. Though it is extremely tempting to simply use JimTCL for this purposes, since we have a copy of jimtcl in cwal's source tree for the configure-script handling, one of cwal's main motivations was eliminating my dependencies on 3rd-party language engines because they invariably change in ways incompatible to my existing code, requiring me to adapt to them.

WHCL introduces a new approach to parsing compared to earlier cwal-based languages. Unlike prior efforts, which parse and evaluate a single token at a time, WHCL tokenizes its whole input before it starts any work, then post-processes that to perform certain translations, then hands off that "compiled" chain of tokens to the interpreter for further handling. This is far more memory-hungry than its predecessors but eliminates the biggest bugbear in s2: re-tokenization of inputs when re-calling the same code (e.g. any loop or function body) is computationally slow. What s2 gains in low memory use, it loses in processing speed. Rewiring s2 for this new model is feasible but would require a large effort. As i truly rely on s2 for many of my web-side CGI applications, i'd rather not risk breaking it at such a low level.

Why TCL-like?

It's fair to ask "why go all old-fashioned when you can go more modern?" i.e. why choose TCL as a model instead of, say, JavaScript or python? In short: s2 already implements something JS-like and python's whitespace policy makes my physically ill. Also, TCL has proven, mainly through the autosetup project, to have a nice syntax for one of the cwal library's biggest initial inspirations: "little languages" intended primarily for use in testing 3rd-party C and C++ code. WHCL is my (second) attempt at building a TCL-ish syntax on top of cwal. The first attempt had some very serious design flaws which were, more or less, corrected in s2. Though s2 works rather well for the purpose of testing 3rd-party C code, much has been learned throughout its development, some of which cannot easily be applied to s2 without breaking it. WHCL is, in short, the next evolutionary step.

Put simply: this is what i do for fun 😀.