To Rev or not to Rev

[Dennis Brown]

On May 4, 2005, at 10:43 AM, Geoff Canyon wrote:

> 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.

I was referring to the "native" instruction words as being like  
assembler.  In fact now days, microprocessors like the G5 etc. have  
much higher level functionality than Forth.  Just as you can write  
macros in assembler that implement a pseudo higher level language of  
your design, Forth gives the same ability in a very convenient  
defined way.  I liked Forth a lot twenty years ago when I was playing  
with it.  If one were to redesign it again today, a much more robust  
set of native words could be created for modern microprocessors and  
methods.  But I have found that the UI is really 90% of programming  
these days, and for that you can't beat Rev.  I just want fast fixed  
type array processing for the other 10% of the program with a  
seamless interface between the two.  Rev is plenty fast for most  
stuff, but an order of magnitude too slow for the array stuff.