Here in late April, how are things going on the list? Well..
-
UTF-8 Everywhere - Being depressingly realistic/conservative, despite having spent quite a lot of time on this in January/February, I'm going to call it half done. There's a level at which it does work...just slowly. Though a lot of progress in other tangential areas needed to be made to get that much going. For instance the relationship between the "device layer" and strings and the core, had to begin using the currency of STRING! values via libRebol. Much of that is now committed with Latin-1 Nowhere.
-
libRebol - There's been a lot of progress on this, though it is a huge design space. As just mentioned, parts of the system that used to speak in terms of weird structs and protocols are starting to exchange data as opaque REBVAL*. I think philosophically, things have shaped up a bit in terms of direction on when a "new API entry point" is justified vs. asking users to use string-based imports...and doing something like a prepared statement for performance. This is a vast task that isn't easy to say when it's "finished"; a lot of hard things have been looked at, there are a lot more.
-
Derived Binding - This got committed and I thought it was done, because it had mechanically solved the problem of making copies. Seemingly it was working great. Yet despite that I know it's not making deep copies of function bodies, the memory profile of a pathological example I tried did not have significantly less memory use than R3-Alpha, and it ran slower. :-/ I'm confident it was "working" but something is going on that will require profiling to figure out, so I'll have to do that. I bet/hope it's something dumb that will be easily fixed.
-
Bring Rebmu Up To Date: I've brought my old projects up to running condition, but Rebmu is going to take a while. It's not just a toy--it has sparked real questions, and it's a way of looking at all the constructs as an organized package. I've realized that one thing it really needs is a kind of macro facility, as I need things like
IE: macro [] [if equal?]which are executable but do not get involved with worrying about proxying any arguments...rather just splice their material into the evaluator stream and let arguments be picked up as-is. We already need this for other reasons, and I've discussed the likes of1 inline [+ 2]being able to produce 3. That's probably the biggest missing mechanic, and while I'm certain it can be done these things always end up being trickier than they sound, when all is taken into account. -
Userspace Stepwise-Debugging and Tracing - I've done a little work on this but the issues involved here are substantial. Some of the biggest problems involve basic questions of how resigned we should be to a single thread, single-Rebol-isolate model. If you say that your debugger is always running on the same thread--in the same userspace as your program--that creates certain limitations. I'm not sure which of those limitations to accept, which to build scaffolding to help make them be understood as more temporary, or whether to try and solve isolates/threading in some more general way. This is kind of the biggest unknown on this list, and it hasn't gotten much more known. (But I do believe FRAME! and other pieces of infrastructure are done quite well for debugging)
EMSCRIPTEN wasn't in the forefront of my mind at first, but despite my natural aversion to webthings--it should be priority #1. I still think an interactive online tutorial--where people don't need to download anything and can play with it--is probably the most relevant artifact we could have around.
We got a big step in progress on that from @giuliolunati, with turnkey emscripten builds. That includes one on Travis-CI, so we don't let it fall by the wayside (as the experiments from previous years kept doing). We can call Rebol from JavaScript, but that's not all that useful compared to calling JavaScript from Rebol and having it react without the Rebol code having to finish all its functions off the stack. So what Giulio has been looking at is how we can:
- fire up Rebol under JavaScript
- have it run a Rebol script that wants to have an effect in the browser (but not yield its state)
- put the Rebol interpreter into a state of "suspended animation", where it is waiting on a result
- while Rebol is in suspension, do arbitrary JavaScript manipulations--post timer messages, get callbacks, return control to the browser
- when the browser gives back control with the effects/information gathered, take Rebol out of suspended animation, so that the interpreter wakes up in the middle of whatever function was running before...but with the effects and information it requested accomplished.
Even if this is done in an ugly way, it would be like the first transistor...a proof of concept, so we'd just work on making it prettier after that. Or as pretty as JavaScript can be. 
I'd been trying to work on a particular aspect of the emscripten build, which is integration with JavaScript exceptions; and getting the part of the debugger that depends on exceptions to work is the hardest bit. So I get distracted, but, it's still what we're aiming for as the "should probably be more important than everything else" thing.
Other neat things have been happening in the meantime, too.
-
We got a New Test Format from @Brett, and I actually went through trying to get all the tests triaged that were hanging around. (Left to add are his date tests and work through the bugs they represent, which were the inspiration for the format change.) A lot of little bugs got fixed, or at least documented somewhere, in that process. And all the test that are committed pass.
-
ELIDE and the "invisibles" mechanic has been pretty much the gift that keeps on giving. A feature I once thought of little benefit beyond "making comments truly invisible" has turned out to have wide-ranging impacts and ramifications on the design. Whether it's being able to splice unconditional code in the middle of a CASE, or lay the foundation for having voids in plain ANY and ALL be errors, or retake the name ALSO for higher purposes, or letting you DUMP variables wherever you want... it's great. I mention that it's the regular discovery of these kinds of things that keeps me interested. So thanks to @MarkEye for provoking me to do it.
-
OR and AND got awesome, and actually motivated a design shift in enfix. There's some real cleverness I think in the way they work, and how they handle GROUP! and BLOCK! on the right.
-
DOES got awesome, SPECIALIZE got awesomer, and finally things like
:append/dup/partcreate efficient specializations, vs just be an error or act weird. -
ME and MY came about, and are good ways of avoiding repeating a variable name.
-
A nifty new generalized COMPOSE (that might need another name) called CONCOCT was assembled rather rapidly, and is working very well. The increasing speed with which we can take feature ideas and put them into action--while having them play well with other features--is exactly what I hoped to see under the "modify with confidence" mantra.
So a lot can happen in not-quite 4 months. I'm going to be traveling a bit, but will have computer(s) with me, so hopefully a lot will still happen, anyway.
I realize not everything coming down the pipe appears to affect everyone's bottom line...in terms of practicalities of apps one is trying to write. But I think the issues of the language core are the bottom line. There are a lot of languages out there that people can use to "just get things done".
I'm not that worried that a working and meaningful language core could be hooked up to some C++ code (or otherwise) to use Rebol to script something. If you look at what the Node.JS guy did, it wouldn't be that hard to copy. IF the language and interfaces were right. But if the language isn't something really-really-special, then today's world is just too saturated for it to get attention.
