I totally agree with Dennis. Efficient arrays are the missing link in rev. Gordon
--- Dennis Brown <[EMAIL PROTECTED]> 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 > [email protected] > http://lists.runrev.com/mailman/listinfo/use-revolution > :::::::::: Gordon Webster :::::::::: _______________________________________________ use-revolution mailing list [email protected] http://lists.runrev.com/mailman/listinfo/use-revolution
