I have been spending an almost unacceptable amount of time
coding lately. After working on FALSE in C, I felt like I
picked up a bit of C and got the workflows down ok. But I
felt like I was fighting a losing battle against memory
leaks, double frees, etc. So I did the logical thing: I
started on a different programming language project. This
time: nimf. nimf was the first non-dsl language I ever
wrote. I wrote it in golang. I quickly abandoned it and
wrote slope instead (which is by far my most usable lang).
nimf is a stack language (concatenative) loosely in the
vein of forth, though perhaps with some concepts either
simplified or more naive depending on how you look at it.
This time around, doing it in C, I initialize a fairly
large block of memory at the beginning:
int memory[6000] = { 0 };
or the like. I don't know from my own memory if 6k is the
actual number. It could always be changed as it is defined
as a macro somewhere. But that memory space gets used to
hold the various state flags (the whole thing runs as a
state machine with a stack), two stacks, and the program
memory. Strings in nimf are 1 indexed and stored with the
length followed by values (`{ 5 'h 'e 'l 'l 'o }`). The
system only knows integers and strings (as described). So
most of the allocations and frees are for various type
conversions, taking input, file handling, and so-on...but
not with nimf strings themselves (under most conditions).
I use a linked list for the dictionary, which stores vars
and words alike (a var is essentially a word that has a
memory address as its only content).
Some things I built into the system:
1. Local variables. Any memory that nimf allocates (from
its block of memory) inside a word is freed up when the
word finishes execution. As a result, all variables are
local by default. To use a global variable you must
declare it in a higher scope. This includes words (proc
definitions): they also get cleaned up from the linked
list when their scope exits.
2. Access, to a certain degree, to syscalls. As a result,
chdir, chmod, cwd, mkdir, rmdir, and friends are all
available by coding in nimf. This is both good and bad
but works surprisingly well (on x86_64, i386, arm, and
aarch64...I did not build in support for others, but it
would be simple to add).
3. Files can be created, opened, read, and written to. So
can tcp sockets (I have read some gopher this way).
4. Loops and Conditionals are closer to a jsr (jump set
return) instruction than regular conditionals/loops. As
such you write things like:
x y = elif truthything falsything
Mostly meaning that they take a word, rather than an
arbitrarily sized block of code. You define the word
first and then give it to the conditional/loop. This is
way less elegant in many ways, but it made parsing so
much simpler it feels worth it. You just have to get
used to it a bit and it isn't too bad. Plus, as stated
in 1 (above) the words you create to complete these all
get cleaned up automatically, so you can mostly think of
them as a block scope that you write first and pass to
your `if`, `while`, `do`, `count`, or `elif`.
5. You can use the `inline` word to grab other files and
run it in the current file. I have not yet worked out
a way to load stdlib stuff without knowing the path of
the stdlib and manually typing the whole thing. I am
sure I'll create a search path for files eventually, or
maybe it isn't really needed. I dunno. If I was using
c23 I could apparently use the `#embed` preprocessor
feature to load the file as a string into the resulting
program and then just parse it as needed to import the
standard libs I have been building... but that feels
like it created a bigger slower thing needlessly, and
I can just put them somewhere on the drive and have a
shorthand to let the interpreter know to look there
instead of a file local to the current file.
Anyway, it has been fun. I have had nearly no issues given
to me by valgrind. Memory is solid. So that is much better
than for my FALSE implementation (a much simpler lang). I
will take that to mean that I am improving not just at
using C, but _thinking_ C and structuring things more
appropriately for the tool at hand. So far the code has
been fast, fun to work with, and a constant puzzle to solve.
I have only gotten really frustrated once: I was trying to
make a `mkdir` syscall to test using syscalls. It kept
coming out with bonkers file modes, and not what I passed.
I kept thinking it was an issue with the umask. After a
few hours I noticed that on the C side I was supposed to
pass the syscall two different vars (the filepath, which
was being passed correctly, and the mode as an int). I was
passing the same var twice. As a result, the int was really
a pointer and was being treated as an int and just giving
me garbage results. Once I fixed the var `kind1` to `kind2`
all was happy.
I'm sure none of this is very interesting to anyone, but
like the lang itself: I have enjoyed writing it. I will
write about non-code stuff next time. Until next time, be
well gopherspace.
