Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

The effect of learning Forth on my understanding of REBOL

 [1/16] from: GedB::Rushcoding::co::uk at: 22-Mar-2007 13:23


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)?

 [2/16] from: btiffin:rogers at: 22-Mar-2007 13:17


Hi, Ged Former (current) Forther. I learned about REBOL from comp.lang.forth Haven't looked back since. Everyone should read Leo's books. My copy of Starting Forth is so rag eared now that I almost want to get a new copy. By the time Thinking Forth came out, our team was so far immersed that we just winked at each other and nodded, Yep, we live here already. Every once in a while I slip RPN in REBOL code. + 2 3 type operations. They are usually mental blips, but the code works anyway, so it stays. I still miss the immersive nature of polyFORTH, with the editor being part of the language itself. There is never any mental context switching while working on Forth screens. No Edit/Compile/Link/Go, or Edit/do, just go/go/go. Perhaps someday I'll quit whining about the issue and finish the immersive.r project I tinker with on and off. btiffin On Thursday 22 March 2007 09:23, Ged Byrne wrote:

 [3/16] from: gregg:pointillistic at: 22-Mar-2007 11:33


Hi Ged, GB> I've been on and off with REBOL for years now.... GB> However, all this changed after spending a couple of months GB> learning FORTH. Suddenly REBOL makes sense. Yeah! That's great. GB> Now I understant how the Stack is used, and how the result bubbles GB> up on it. Now everything is obvious. If you could post some thoughts on this, it might help others. That is, how *do* you visualize that code working now. GB> Are many REBOLers former FORTHers? Does anybody else think that GB> Ian Brodies Thinking FORTH should be required reading (or better GB> still, adapter into Thinking REBOLisouly)? I have 'Thinking Forth' here, but didn't read it until after spending much time with REBOL, and even then, didn't study it in depth. Maybe I should. 'Threaded Interpretive Languages' is another good one, showing how TILs work internally, and how to build them. I also really enjoyed the Brian Harvey 'Computer Science Logo Style' series, in a REBOL context. I think 'Starting Forth' and the Brian Harvey books are available online now. Not sure about 'Thinking Forth', and it's out of print and hard to find. -- Gregg

 [4/16] from: tim-johnsons:web at: 22-Mar-2007 11:02


On Thursday 22 March 2007 13:23, Ged Byrne wrote:
> 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

 [5/16] from: moliad:gma:il at: 22-Mar-2007 15:01


Ged, I remember and loved that moment when everything just lit up... I think most of the old time rebolers have had that moment, and fundamentally understand WHY they like REBOL. Have fun REBOLing! -MAx On 3/22/07, Tim Johnson <tim-johnsons-web.com> wrote:

 [6/16] from: compkarori::gmail::com at: 23-Mar-2007 8:08


Thinking Forth is online now as a downloadable pdf. -- Graham Chiu http://www.synapsedirect.com Synapse-EMR - innovative electronic medical records system

 [7/16] from: andreas:bolka:gmx at: 22-Mar-2007 21:38


Thursday, March 22, 2007, 9:08:17 PM, Graham wrote:
> Thinking Forth is online now as a downloadable pdf.
There: http://thinking-forth.sourceforge.net/ -- Best regards, Andreas

 [8/16] from: rasmussen:bryan:gma:il at: 22-Mar-2007 21:50


I'd always thought it pretty obvious that Rebol fit somewhere in the Lisp family, I don't know anything about Forth and am finding the description of its Forthness surprising, so I would like, as someone further up the line asked, some pointers on how people see Rebol as Forthlike? Cheers, Bryan Rasmussen On 3/22/07, Tim Johnson <tim-johnsons-web.com> wrote:

 [9/16] from: anton:wilddsl:au at: 23-Mar-2007 13:12


Well, I'm learning Factor ("a practical stack language", similar to Forth), and it has some similar words to Rebol, like "append", "join", "reduce". I'm not sure but these probably have common roots in Lisp. Having the stack there just makes it obvious how the arguments are passed and returned. Implementing a DLL library interface for Factor clarified for me what compiled C code is in fact doing when it calls functions. Anton.

 [10/16] from: carl:cybercraft at: 23-Mar-2007 18:00


On Thursday, 22-March-2007 at 13:23:26 Ged Byrne wrote,
>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)?
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.

 [11/16] from: gabriele::colellachiara::com at: 23-Mar-2007 12:24


Hi Ged, On Thursday, March 22, 2007, 2:23:26 PM, you wrote: GB> Are many REBOLers former FORTHers? Does anybody else think that Ian GB> Brodies Thinking FORTH should be required reading (or better still, GB> adapter into Thinking REBOLisouly)? I came to REBOL just after learning FORTH too. Probably just a coincidence... but maybe not. :) Regards, Gabriele. -- Gabriele Santilli <gabriele-rebol.com> --- http://www.rebol.com/ Colella Chiara software division --- http://www.colellachiara.com/

 [12/16] from: GedB:Rushcoding at: 23-Mar-2007 13:18


On 3/22/07, Gregg Irwin <gregg-pointillistic.com> wrote:
> If you could post some thoughts on this, it might help others. That > is, how *do* you visualize that code working now. >
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 :)

 [13/16] from: GedB:Rushcoding at: 23-Mar-2007 13:21


Bryan, I've tried to understand REBOL by learning more about LISP, but it never quite worked. LISP is functional, with the change of state being something to be avoided. REBOL, on the other hand, seems to encourage tinkering with the context. This is a style FORTH reflects. On 3/22/07, bryan rasmussen <rasmussen.bryan-gmail.com> wrote:

 [14/16] from: moliad::gmail::com at: 23-Mar-2007 9:13


thanks for this thread Ged, Its my first real brush with FORTH, and you've just explained/confirmed what I was about to develop wrt antidote's (see other thread) stack handling. so its seems I am on the right path. I understood stacks a long time ago with my amiga... I had many stack overflows in some application and I had to come to grips with a btree algorythm which was just going in circles. The information required to program on amiga really forced many developpers to become quality developpers... you could not overlook linked-lists, semaphores, garbage collection (pools), resident applications, graphics, there where so many advanced concepts given directly to you in the api... its still something I miss somehow. everything was bare and accessible, real control. yet having everything plainly documented and properly designed, meant that if you followed the few simple rules... you could litteraly rewrite the OS from the inside out! -MAx On 3/23/07, Ged Byrne <GedB-rushcoding.co.uk> wrote:

 [15/16] from: lmecir::mbox::vol::cz at: 23-Mar-2007 19:58


Ged Byrne napsal(a):
> 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. >
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.
> 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. >
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

 [16/16] from: moliad::gmail::com at: 23-Mar-2007 14:41


On 3/23/07, Ladislav Mecir <lmecir-mbox.vol.cz> wrote:
> > Again, the things are simpler - it is not a stack, it is just "result > place". Example: > > 1 2
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