The effect of learning Forth on my understanding of REBOL

I've been on and off with REBOL for years now. I'd try it for one purpose, and get blown away be the expressive power. Then I'd try it for something else and wind up hopelessly muddled. I'd reached the conclusion that I just wasn't smart enough. However, all this changed after spending a couple of months learning FORTH. Suddenly REBOL makes sense. Take the examples from the 'Whats Wrong With Ruby' thread: a: if arg [red] color: any [ all [arg arg2 green] if arg [red] if arg2 [black] purple ] I struggled for a long time understanding how it worked. I was at the point where I could use them, but just couldn't visualise what was going on. Now I understant how the Stack is used, and how the result bubbles up on it. Now everything is obvious. Are many REBOLers former FORTHers? Does anybody else think that Ian Brodies Thinking FORTH should be required reading (or better still, adapter into Thinking REBOLisouly)?

Not me, but according to Carl rebol is also inspired by lisp. When I read that I starting playing with lisp a bit. Actually, most of the lisp writing I have done is in elisp (emacs version of lisp). I find that playing with lisp helps my rebol coding. tim -- Tim Johnson <tim-johnsons-web.com> Palmer, Alaska, USA

There: http://thinking-forth.sourceforge.net/ -- Best regards, Andreas

I learnt FORTH a decade or more before I encountered REBOL, and ditto for LOGO, both of which are languages you extend by adding new words to. So I'm sure that helped me to get to grips with REBOL, as did FORTH's reverse-Polish-notation and stack approach. For some reason, I remember FORTH much better than I remember LOGO. Encountering such different languages early in your programming life is a very good thing I think, as apart from making you realize there's other approaches to language design, it must be hard to switch from (say) just imperative languages after you've been using them for many years. REBOL does suffer from the same problem as FORTH and LOGO due to the 'adding new words' ability though, in that code can be filled with words you won't find in the default dictionaries. This can make the 'learn by examing some code' approach to getting to grips with a new language difficult. I found learning by writing code to be the best approach. -- Carl Read.

The main breakthrough is 'what does a word do'. My thinking was strictly imperetive, so every word is a procedure to be executed. So if you have 'red', what does it do? Apparantly nothing. So if you have 'a: if arg1 [red]' what happens when red is executed? Nothing? My understanding before was that a block is an anonymous method with an implicit return. The actual code being executed was 'if arg1 do [return red]'. Obviously If returns whatever is passed to it. This was all very complicated, and never quite fitted. It was all just too Ptolemaic. To be honest, I would write if arg1 [a: red] just so I could keep a track of it all in my head. Now I see that what red does is place something on the stack, where it remains until something picks it up. 'if' just leaves the stack unchanged. However, unlike FORTH, REBOL enforces a scricter scope. I imagine that a: sets an expectation for a token, which needs to be satisfied within a specific scope. The stack is cleared once the current scope is left. This removes the need for reverse polish and constant drops. This is why 'a: if false [red] if true [blue]' returns none rather then blue. This leads us to the need for the 'all' and 'any' words, and what the difference between them is. These are commands that control the scope. I'm sure my mental model will need further refinement, but it is a serious breakthrough for me :)

This explanation is arguable, I guess. A block doesn't return anything except for itself. The function IF is needed to evaluate the block to yield the RED value when ARG1 is considered true. The other case is, that ARG1 is considered false by IF. Even in that case IF has to return a value, which equals to NONE in that case.

Again, the things are simpler - it is not a stack, it is just "result place". Example: 1 2 is an expression in REBOL yielding 2, since 2 replaces 1 in the "result place". I don't know whether this can be of any help to you, but it looks more accurate to me. -L

my understanding follows your logic ladislav... actions push the result of evaluating expressions on the stack until a specific number of results have been accounted for. so: 1 2 will not be pushed, since there is no function arguments being pushed on the stack. but I think the "return space" could also be the 0 stack offset of the callee's arguments. this could actually simplify evaluation of expressions... since the push needed to be done by the calling function will be already done by the returning function. and some functions knowing that they return first arg they received wont even have to touch the stack a part from popping their local vars. :-) -MAx