Hi, I've been programming since the mid-70s, first in FORTRAN IV and the proprietary language of the Olivetti P652. Various BASICs around 1980. Then lots of C. Switched to Haskell as my primary language in 1992 (but don't really like the complexity it has acquired over time). For the little programming I do nowadays I use C++ when speed is an issue and I'm looking for a language for those occasions when it isn't as much an issue. That's how I encountered Rebol/RenC/Red a few weeks ago.
4 Likes
Hi @okram, glad you found us! What was it about our quirky language caught your eye?
The language-orientation caught my eye at first. The (related) notion of "meaning depending on context" drew me in more.
Hello @okram ...
I can speak pretty directly to your background, as I also started out on BASIC (Osborne 1) somewhere around the start of the 80s...and worked mostly with C and C++, with some pure-functional-programming envy and Haskell dabbling here and there.
Good to hear you're looking for something that can run slowly, as that is one of the few incoming expectations I can guarantee we can deliver on. 
In terms of setting those expectations, Ren-C is still very much in the design process. It isn't pitched or advertised as something that is a good pick for one's professional obligations or if you care about deadlines--at least not at this time. It's more an off-the-beaten path exercise in programming meditation...a bit like a Zen gardening experiment. I hope it applies to more than that, but wouldn't promise it.
You seem to be doing a pretty good job of orienting yourself and seeing what the lay of the land is, but do post about any questions you have.
My opinion is that Rebol's "rebellious" anti-academic and anti-formalist roots painted it quickly into a corner (a corner that Red beelined for and is seemingly very happy in, for reasons that are beyond me). While every system hits limits in composability, you'd hit limits almost instantly if you veer off the script of the few examples. To me that winds up being much more like an "app" than truly a language...I feel the point of language is that if someone combines parts in ways that haven't been tried before, there's a basis for that working.
But what was interesting about Rebol2 to me is kind of like the story of what's impressive about a singing dog: it's not that the dog sings in tune, it's that it sings at all. The execution and binding model was painfully naive-seeming, and yet you could solve many tasks with it. Ren-C's effort is to get everything tuned up to where the language parts are more credible and composable, because I think Red's plan of just rehashing Rebol2 at a language-level is "we've already seen that, and it's old news".
It's a long hard effort, because the medium has inherent limits. But exploring it has shown some pretty interesting stuff, I think.
2 Likes
@okram, since you have Haskell experience I'll assume you're familiar with Parsec... I'd like to draw your attention to a current interesting design point..
I'm trying to transition PARSE from its ad-hoc C implementation into something based on parser combinators. While some combinators could be natives backed by a C implementation, others could be plain user functions. The effort is called UPARSE.
As with most parser combinators, this makes each one process both how far it gets on the input (or a failure signal)...which is separate from a generated value. The concept is distinct because the combinator for a SET-WORD! (and others that are "value gathering") triggers a demand for a generated value to the combinator. If that demand is not there, the combinator can run in "skip mode" and be faster.
Having the combinators return higher-level constructed values than merely having "how much input was consumed" is a much-needed aspect. But I think there's something interesting about how it accomplishes the effect of implicitly passing the parser input through a driver that does FRAME! specialization. It strikes me as a much easier-to-grasp mechanical concept vs. the more strict monadic approach, which could be used by other dialects.
It will be slow for a while as it is uses many unoptimized features (e.g. multi-return, which is prototyped as all usermode code... that's actually scanned and LOAD-ed on every SET-BLOCK! invocation right now!) and is all usermode. But it's just to hammer out the design.
I've been raising points in the PARSE category that could use informed opinions...!