(2023-04-26) Making VTL more AWKward
------------------------------------
First of all, I have created a restricted variant of my LVTL-O
implementation, called LVTL-R. It limits the amount of generic variables to 
A-Z, disables input evaluation (only numbers are accepted, as in VTL02sg) 
and makes the ! and # operators the only possible versions of "or" and 
"xor". To be honest, it didn't help with any SLOC count reduction compared 
to the full-featured LVTL-O, so I'm not even sure it's worth publishing. If 
I do publish it, it will be in the same shar as the updated LVTL-O. Because, 
obviously, if I find any bug in LVTL-O, it must be fixed in LVTL-R as well.

All these C versions are cool and fast but there is a small problem: they
require a compiler to work. It's not always possible to cross-compile LVTL 
from your host PC for some embedded system (especially if it's something 
more exotic than a regular ARM), not even talking about trying to compile it 
on that embedded system itself. So you're basically stuck with the Busybox 
and...

Wait. If this particular Busybox has awk command applet compiled in, it's
something we can already live with. Because after I figured out all 
essential VTL-2 implementation details and wrote the reference code in C89, 
porting it to AWK turned out to be a piece of cake despite I don't know AWK 
as much. AWK allowed to simplify a lot of things, including the overall 
program execution flow and memory management, of course. Not without its own 
quirks (like the fact that all arrays in AWK are associative and 
string-keyed) but it took several hours to port and test my restricted 
flavor of VTL-2 to this language **and** make it compatible with both 
Busybox and GAWK (btw, I'm not sure what other flavors support bitwise 
operations, but they are absolutely vital here). For instance, I was a bit 
surprised when I discovered that GAWK doesn't support multiple 
pre-assignment in for loops while Busybox AWK allows them. I.e. a construct 
like for(i=0,l=length(s);i<l;i++) {} will be valid in BB but raise a syntax 
error in GAWK. Well, the more you know.

Surely my scripted implementation of VTL-2, which I called LVTL-W and
published on hoi.st as lvtl.awk, is quite slow (especially on BB), because 
essentially it's an interpreter running inside an interpreter. But it still 
is useful, and I, for instance, enjoyed playing Bulls and Cows on it as 
well. This way, I don't even have to look for the native AWK implementation 
of this game because I already have the VTL-2 version up and running. You 
might ask a question like "why implement an older scripting language in a 
newer scripting language that's more superior by itself?" Well, the answer 
is simple: to preserve the older language AND all the software written in it 
by making it possible to run on as much hardware and as many runtime 
environments as possible. Besides, it's a great benchmarking tool as well: 
if some VTL-2 program doesn't display any slowness when running in LVTL-W in 
BB-AWK, you can be sure it won't be slow anywhere else.

Now, I have plans to port LVTL-R to some more platforms. But before I do
this, one more concept needs to be designed. And no, I didn't forget about 
compression.

--- Luxferre ---