What would it take for me to kick off this process and build a minimum viable rebol interpreter as a learning exercise?
I've recently been interested in the a "make a lisp" project as a powerful learning tool for both learning lisp and for learning other languages. Does anyone have any thoughts as to the feasibility of this for rebol?
I understand that having a good vetted implementation for doing "real work" like Ren-C or Red is important (keep the WASM build coming), but I'm coming to believe that some of the staying power of lisp is that in terms of choosing dependencies for long term projects something that you can build from scratch with dozens of examples is pretty good future proofing.
From my tinkering with things like the English Language Learners Stack Exchange, I have found that some natural-feeling systems that become extremely popular have inner rules that you might find it hard to simply lay out. Efforts to simplify have failed. The real question is whether the medium permits expression how you want to express yourself. Simpler, predictable systems are unlikely to be expressive enough for human needs.
So we're not trying to build a Lisp or lambda calculus. Those have already been done and what we observe is that people are looking for if-then-else and glomming onto things like RegEx. This is an impedance match of evaluator-driven systems to human needs.
I'm happy to explain my thinking but the comments are probably better than anything else I can say right now.
I think we have enough to do with this particular one minimal viable Rebol interpreter at hand.
Remember that Rebol is striving for a minimal footprint in its very nature.
So instead of starting a new one, just help with this one.
@iArnold The point of "make a lisp" isn't to build competing implementations but rather to understand how lisp itself actually works. I'm not suggesting making a competing rebol implementation. Rebol is minimal when you compare it to Python or Java but it does have a lot of builtins that make real programming useful (like email address and url primitives etc). Things like the ODBC extension are important features for non-power users of rebol, but I'm really only talking about people that are interested in language design (contributing to a major rebol implementation) or really understanding the language on a deep level. As a potential contributor to rebol building your own purely instructional interpreter for rebol would probably be a fast-track to understanding the whole project with all the bells and whistles.
@hostilefork I never really understood the value of the meta-circular interpreter except as sort of a "wow cool our language is simple" kind of thing. Interestingly though rebol is one of the examples on the wikipedia page so it seems that road has already been gone down.
My notion isn't really about writing a new codebase or adding features, rather than an instructional resource that explains the implementation and how to build one. I suppose you could object to this if you are trying to cultivate a brand that is distinct from lisp.
As per Crockford, maker of "JSON", former Rebol community member:
"Rebol's a more modern language, but with some very similar ideas to LISP, in that it's all built upon a representation of data which is then executable as programs. But it's a much richer thing syntactically."
"Rebol is a brilliant language, and it's a shame it's not more popular, because it deserves to be"
The influences are clear but as Andreas said, those who expect Rebol to be like Lisp will soon learn it is not really that close at all.
I'm not suggesting a comparison of the languages themselves, but rather just take one way of learning about the language that has seen some success and apply it to rebol. I'm talking about "rebol" in general not the Ren-C implementation in particular. There are similar exercises in building interpreters for forth, brainfuck, etc.
I guess its sort of a pointless discussion post since I'm not bringing something to the table, but I just wanted to see if anyone had any ideas, previous art, etc.
Bringing a discussion to the table is very much welcome.
Ren-C has gone through a bit of evolution in terms of its mechanics, and they are subtle... if you are interested in the topic maybe you would find this kind of thing interesting:
It's hard to suss out all these rules in a simpler way than the code we have; and I would be happy to help if you want to try, but I'm also trying to get it right in the first place....
