So I'm back. I did not manage to start before christmas because all my OS shenanigans, but I got back to it as soon as I could.
Before I get to the main questions, lets go throgh few changes I made.
Turns out, I actually started this project on FreeBSD!
Well, linux gcc was not really happy to see what I made there. You see, there is a thing called 'ISO C'. This version of C tries to be as multiplatform as possible. For reasons far beyond me, some platforms might have different kind of pointers for data and functions. Due to this, you are not allowed to cast data pointers to function pointers.
Sounds good, right? Well, turns out 'void*' is a data pointer. OK, just make your interface functions take specific function type instead, r i g h t ?
WRONG!
For opening shared objects, you use 'dlsym' defined by POSIX. Despite ISO prohibiting it, POSIX decided to make this very important function return void* anyways, trying to fix it by saying that it will always return valid function pointer, no matter the platform.
So, to use dlsym, you need to defy ISO. NICE. Luckily, the warnings gcc produced were only caused by the '-pedantic' flag. After trying some crude hacks and finding out that nothing works, I decided to remove it from 'csrc/CMakeList.txt'.
'S\"' is a standard FORTH word for creating a string with escape characters. pforth supports all the required escape chars as stated in the standard. Gforth adds a few others. The one I used is '\0'. (which is not even mentioned in the manual, I mean, it does say they are mostly the same as in C, but '\0' is still not on the page)
OK, adding extra escape was not hard. It might be a bit redundand, as '\z' already does the same, but it is in there now. But there is moore...
Lets say that I open a REPL and enter the following code:
s" 123" s" 456" type type
What will happen?
In pforth, outcome will be '456456'. In Gforth, it will be '123456'. This is because Gforth compiles interpreted strings like normal, but pforth stores them in the 'PAD' buffer.
Up until now, my goal was to make Gforth compatible implementation, but still keep compatibility with pforth. I even kept the compile-extra-words option and respected the no-float option. (which was mostly to allow smoother merging, but I still kept it there) But now, I can no longer support both versions.
I can not even ignore it for now, as I use this Gforth behavior a lot in gforth-tetris. I could rewrite it, but the point was to make ex:forth complient with it.
So what now? One of them must be doing it wrong. lets look at the standard and...
Interpretation semantics for this word are undefined.
Great!
So, originally I didn't care for pforth and chose it only as a good base for my own implementation, so Gforth way it is then.
Wait!
Scroll into the comments and you will be guided to the extended 'S"' definition from the 'File-Access' word set.
Store the resulting string in a transient buffer c-addr u.
So wait! Is Gforth the one doing it wrong?
Well, now it feels wrong to break the perfectly standard-obeying pforth version for the broken Gforth one. Damn you GNU implementations. You always have to fuck with every standard you come across.
I dont know.
I might give up on making Gforth-compatible implementation and instead just do my thing. Being able to run the tetris was only a cool idea that was supposed to give me a clear goal and a path that would lead to adding some useful features. I can always just rewrite it.
Sure, some features of Gforth are cool, but I would not be able to make 100% Gforth one-for-one replacement anyways. I have some words I would like to add, but I can add those even if some things are different.
I will probably focus on implementing the (partialy) missing optional word sets:
(we'll see about doubble and xchar)
Then write some documentation, add Windows support (should not be that hard) and release version 1.0.
Yea, and also rewrite the tetris, so that I have something to demonstrate on.
How long will I take, no one knows. Depends on how much Lisp will cross my way. I'm also constantly looking into some old/obscure languages.
Time is weird...