To Rev or not to Rev

[Geoff Canyon]

On May 2, 2005, at 8:02 AM, Dennis Brown wrote:

> On May 2, 2005, at 10:25 AM, Geoff Canyon wrote:
>
>
>> I'm not sure how to catalog Forth, but it's not OO (inherently --  
>> there are OO implementations). It's procedural, certainly, but the  
>> inherent stack gives it a definite functional feel.
>>
>
> Forth is not really a high level language any more than assembler  
> is.  It is an alternative machine language based on a double stack  
> architecture.   There have been hardware implementations of Forth  
> as the native machine instruction set.  When emulated, the "Code"  
> just consists of a list of addresses to the actual machine code for  
> the native functions, or addresses of  "higher level" defined  
> function (uses a flag bit to tell which).  This makes it execute  
> much faster than "byte code".  You can implement a higher level  
> language within the syntax of Forth because of its extensible  
> nature.  "Words" are defined from other words in an interpretive  
> environment.  Because of the double stack architecture, data  
> arguments are passed and returned on one stack and return addresses  
> are in the other stack.  It makes a very efficient and powerful  
> architecture for developing real time machine controllers with a  
> tiny amount of memory.  You are free to define "words" that  
> implement an OO environment if you choose.  You could even create  
> Rev using this as the lower level "P code", or an operating system  
> for that matter.

I understand how Forth works. I'm just not sure how I would  
categorize it. On further reflection, I would say that Forth is  
functional in about the same way that Revolution is Object-Oriented.  
In other words, loosely. ;-)

I disagree that Forth is no more high-level than assembler is. The  
built-in extensibility of Forth syntax makes it much more than just a  
convenient way of handling machine language.

gc