Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uwm.edu!linac!att!cbnewse!cwpjr From: cwpjr@cbnewse.att.com (clyde.w.jr.phillips) Newsgroups: comp.lang.forth Subject: Re: Forth in CS Summary: CS? Everything deleted but CS keywords - You decide Message-ID: <1991Mar4.143704.13146@cbnewse.att.com> Date: 4 Mar 91 14:37:04 GMT References: <9103031944.AA02112@ucbvax.Berkeley.EDU> <1991Mar4.050505.27571@csi.uottawa.ca> Distribution: na Organization: AT&T Bell Laboratories Lines: 116 In article <1991Mar4.050505.27571@csi.uottawa.ca>, cbbrowne@csi.uottawa.ca (Christopher Browne (055908)) writes: > Unfortunately, the extensibility is not one of the topics that typical > language theorists are interested in. Are CS people only interested in "language Design"? No wonder they don't respect FORTH, it says they have no clothes... > Language design courses generally involve defining Is this the heart of CS? > Computing theory is not happy with languages that are not constant Is this the heart of CS? > Forth will be interesting to people into architecture design - Some how I thought this was more central to CS... > it does lots of neat stuff Thanks. > ugly for the theoretician to work with... > Well most FROTH programmers advance theories call programs and they Appreciate FORTH for it's real world "ugliness" > Yes, you can define new data types. Unfortunately, this tends to be an > ugly operation. See above People have developed OOP words, but ADTs are not yet > generally done in a pretty fashion in Forth. see above > Yes, you can define new "operations"/procedures/words. That's been > possible since FORTRAN. Subroutines are hardly a new concept. But ones that work in hardware are. Certainly, > Forth does 'em somewhat differently than most other languages do - with > both advantages (no major set-up work), and disadvantages (interfacing > through the stack can get really cryptic). Ever see the cryptic C contests? But subroutines are NOT new. > > What "new" control structures have been created in Forth? I'm not sure > Forth has introduced ANY new control structures... But youre point was we don't abide by CS. If we use every existing control structure you guys have why would we need new ones just to distinguish ourselves? ie... > DO .. LOOP - That ain't new... > IF ELSE THEN - That's not unique to Forth either... > BEGIN / REPEAT / WHILE / UNTIL / AGAIN > - The combo's of these words are not unique to Forth > CASE statements with various variations - NOT unique - see C/Pascal > JUMP Tables/Vectored Words > - Have been used in Assembly Language for years... > RECURSIVE/RECURSE - Found in everything but FORTRAN and BASIC > > If I've missed any control structures that are common in Forth, let me know. > I don't think that ANY will be found that are not commonly found in many > other languages, in some form or another. I don't see a customized "case" > to be a new control structure - it's merely a more convenient FORM of the > case statement. > > For NEW control structure forms, check out Pancode (SIGPLAN, sundry issues > over the past 3 yrs.). If people were implementing Pancode in Forth, I > ^----- (or some other similar project) > might agree that there was "theoretical control structure" work being done > in Forth. As things stand, I don't see any TRULY interesting control > structures coming from Forth. > Neither in C so why a bias? > In compiler design, Forth IS interesting as a "virtual assembler." Prof. > Tannembaum of MINIX fame (could I have misspelled his name?) has done work > on a compiler system which involves a front end parser for the language of > your choice (C, Pascal, Modula2, possibly some others), and translates the > code (with some optimization) into a stack-based (and thus SOMEWHAT > Forth-like) language. This code can then be translated through a back-end > optimizer to the processor of your choice... 68K, 80x86, perhaps others... > The use of the internal language allowed there to be better optimizations, > and for a change of initial language (from C to Pascal) to require NO > machine-dependent code. ALL of the machine dependent code would be written > to "implement" the stack-based language on the given machine. > > I've also seen some compiler design books that suggest that "Forth-like" > languages are useful as parts of a code generator. Typical expression > parsing involves converting algebraic notation to RPN, and Forth is great > for processing RPN stuff... > > But that's NOT theoretical computing, that's pretty nitty-gritty coding. > "An elegant form of programming language implementation", YES. > > The people that spend their time writing about LALR(1) parseable languages > don't want to KNOW about Forth... > I guess I should have looked at your bottom line... > -- > Christopher Browne > cbbrowne@csi.uofottawa.ca > University of Ottawa > Master of System Science Program Clyde