To Rev or not to Rev

[Gordon Webster]

I totally agree with Dennis. Efficient arrays are the
missing link in rev.

Gordon


--- Dennis Brown <see3d at writeme.com> wrote:
> 
> 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.
> 
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
>
http://lists.runrev.com/mailman/listinfo/use-revolution
> 

:::::::::: Gordon Webster ::::::::::