In the *nix world, everything seems to be an acronym, so it is only natural if you expect Stril to be an acronym too. Perhaps it stands for "string language" or "strange, interpreted language"? It could also be an actual word in its own right. In Norwegian, a Stril is a person from the rural areas outside the city of Bergen. I grew up in one of those areas.
Stril is a strange little program. It could be seen as a cross between Pilot, Awk and a macro processor. I started writing it in October 2017. At first I intended to write my own Pilot implementation in assembly language, but I couldn't resist the temptation to add new features. The final result is an interpreted programming language with around 30 different commands that often kill several birds with one stone. The source file contains less than 2000 lines of assembly code, comments and empty lines included. Fasm by Tomas Grysztar is needed to produce the Stril binary from stril.asm. The Stril binary is approximately 13 kilobytes in size.
I was fairly rusty when I started this project. I hadn't written a single line of assembly for more than ten years. I am not quite sure why I started the project. Perhaps I just wanted to see if I still had the ability. I was disappointed at first, but I kept at it, and this is the result. As it turned out, my planning skills were at least as rusty as my coding skills. I rewrote the code again and again and again. I discarded functions, wrote them out of the program and into it again. By and by, some design goals started to emerge.
Needless to say, I had to compromise, but all commands share a unified syntax. In the end, I gave priority to an easy learning curve over functionality and to functionality over execution speed. I did, however, manage to keep down the size of the scripts. The HTML-converter that is used to generate the documentation, is approximately 400 bytes in size, and that includes the style sheet.
That said, this is the first release, and it should be regarded as a beta version. I have not decided on a permanent license yet, but the beta version is free for personal, non-commercial use. Your only obligation is to send feedback and bug reports to jonegilkorsvold@gmail.com. Since this is a beta version, there is no warranty at all. If you decide to use the program, you do so entirely at your own risk. Your decision should be informed, so here are some good reasons to stay clear of Stril: I am not young and bright anymore. I have been a hobby programmer for a long time, but I am not an educated programmer. I hold university degrees in linguistics, anthropology, history and religion, but I have not acquired a single credit point in computing. Besides, it is fairly hard to avoid bugs in assembly language programs, and they tend to be rather hard to spot and eliminate.
Pilot was invented around 1960, mainly as a teaching tool. It was meant to be an easy to learn, user-friendly first programming language, much like Basic. In Pilot, all commands were single letter ones. When Pilot was created, close attention was paid to mnemonics. "J" meant "Jump" and so on. I have kept that feature, but I have increased the number of commands substantially and applied the single letter principle to variables as well. Allowed variables are a-z and 0-9. If you placed "#" in front of a variable in Pilot, it was a numerical variable. "$" was used for string variables. In Stril, there is no such distinction. "|" is used for all variables. Inside a computer, there are only numbers. An ASCII "0" has the numerical value 48, "A" is synonymous to 65 and so on. In Pilot, a line could be no longer than 127 bytes. I have kept that limit, but it only applies to variables and the length of the text option of most commands. Pilot could do math. Stril can count from 0 to 126, and that is it. No more is needed to reference the positions in a variable or the ASCII range of characters. Pilot was case insensitive as far as commands were concerned. Stril is all lowercase. Although the syntax of Stril is inspired by Pilot, Pilot cannot run Stril code, and Stril cannot run Pilot code.
Awk has often been my programming language of choice. I have used it for cgi-scripts as well as conversion from one format to another. When I decided to write my own language, I wanted a language with the functions that I use most frequently. Most Awk implementations support arrays, so I wanted that too. I ended up with a strange design. The internal variable "current" points to another variable. To refer to the next variable, you increase current. In this way, |a-|z can be used as an array, but it is, of course, a very limited one. |0-|9 can be used as an even more limited array, but that should be avoided in most cases. |0-|3 are used by some internal functions. Most Awk implementations contain a system command. In other words, they allow you to spawn a child, open a shell and use a string of *nix commands. The x-command in Stril does the same.
At the core, however, Stril is perhaps first and foremost a macro processor. When it prints a text, it looks for variables and expands them. Variables and backslash codes within variables are permitted. Stril also provides several different ways to define and manipulate variables.
When I started writing Stril, it was merely an intellectual exercise, much like a crossword puzzle. Optimal speed was not in my mind at all, a fact that is still evident in the code. Stril reads program files and input files byte by byte. That is fairly slow going. It would be much faster to read a file in one operation, store it in a really big buffer and then parse the buffer. A big buffer would, however, increase the size of Stril substantially, and a small buffer would limit the size of the input files. The byte by byte procedure is slow, but it is also scalable, allowing Stril to process files of any length. Most interpreted programming languages are actually parsed byte by byte, but the bytes are loaded from memory rather than read from a hard drive. Stril doesn't have to use a hard drive. If you want to speed it up, the obvious solution is to copy your scripts to a ram disk and let Stril read from memory. A byte by byte writing procedure would impose an unacceptable performance penalty. The print command writes at most 127 bytes at a time, less if the lines in the input files are shorter or contain embedded variables. Stril does not have a byte code compiler, but the syntax is so terse that it could be argued that you write the byte code. If you hand Stril a big print job and compare it to *nix cat or a modern Awk implementation, the competition will be several times faster. Speed is, however, not only about execution speed. Typing speed is also important, as well as coding speed. All Stril commands, operators and variables can be typed with one finger. You do not need to touch shift, alt or ctrl. Your coding speed will probably not be fantastic the first time you try out Stril, but once you have gotten used to it, you can do a lot in a few hundred bytes of code. Stril is not well suited for large applications.
I have not borrowed code from anyone, but still, I find it proper to give credit where credit is due. While I was working on Stril, I frequently needed to refresh my limited knowledge of assembly language programming. I read my own ancient efforts, but I also read the code of Brian Raiter (elf kickers), parts of the source code of Fasm by Tomas Gryzstar and the lscr-project by Roman Ovseytsev, Jonathan Pleski and Bogdan Drozdowski. I found the system calls reference of the lscr-project especially useful. I have also used "rpilot.txt" in Rob Linwood's Rpilot and several pages from the Linux man-pages project during the work on Stril. The blame for Stril rests exclusively with yours truly:-)
Jon-Egil Korsvold, September 16th 2018.