UNBCIC@BRFAPESP.BITNET (03/02/91)
> C is much farther advanced than Forth in the realm of Computer > Science just on the basis that it has a built in type system. Forth > basically "encapsulates" none of CS. It is a hack. Forth and C > both leave it up to the user to decide how to factor and to use other > good programming techniques. No, C has just types, and have no strong typing, so it's weak in this respect. TYPEDEF just defines macros. It doest'n have abstract data types also. C++ is another history. Forth can have abstract data types and, consequently, strong typing. So, although Forth has no built in type system, it can have much more efficient data type than C. > Forth doesn't address any of the language issues that are discussed > in CS courses. What new programming language concept has Forth > contributed? Forth is simply an elegant form of programming language > implementation, it is nowhere in terms of language theory. Wrong again. Forth has EXTENSIBILITY, wich my Programming Languages book defines as the capability to define new (abstract) data types, new operations (procedures) *AND* new control structures (Programming Languages Concepts, by Carlo Ghezzi and Mehdi Jazayeri, copyright by John & Sons, Inc., chapter 5, item 1.5). Forth has all this capabilities. (8-DCS) Daniel C. Sobral UNBCIC@BRFAPESP.BITNET
cbbrowne@csi.uottawa.ca (Christopher Browne (055908)) (03/04/91)
Unfortunately, the extensibility is not one of the topics that typical
language theorists are interested in. Language design courses generally
involve defining some sort of Pascal subset, and then writing a compiler
for that subset. Computing theory is not happy with languages that are
not constant in their definition... There may be a comment in A text, but
Forth's "strong points" are NOT seen by language theorists as theoretically
interesting.
Forth will be interesting to people into architecture design - it does lots
of neat stuff with respect to memory allocation (or lack thereof :-)),
registers, stacks, pointers, and the like. THOSE things are the basic
building blocks that the Forth programmer works with. They are far too
ugly for the theoretician to work with...
Yes, you can define new data types. Unfortunately, this tends to be an
ugly operation. People have developed OOP words, but ADTs are not yet
generally done in a pretty fashion in Forth.
Yes, you can define new "operations"/procedures/words. That's been
possible since FORTRAN. Subroutines are hardly a new concept. 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). 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...
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.
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...
--
Christopher Browne
cbbrowne@csi.uofottawa.ca
University of Ottawa
Master of System Science Programcwpjr@cbnewse.att.com (clyde.w.jr.phillips) (03/04/91)
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
bouma@cs.purdue.EDU (William J. Bouma) (03/05/91)
In article <9103031944.AA02112@ucbvax.Berkeley.EDU> UNBCIC%BRFAPESP.BITNET@SCFVM.GSFC.NASA.GOV writes: >No, C has just types, and have no strong typing, so it's weak in this respect. >TYPEDEF just defines macros. It doest'n have abstract data types also. C++ is >another history. Forth can have abstract data types and, consequently, strong >typing. So, although Forth has no built in type system, it can have much more >efficient data type than C. It is not what Forth CAN have but what it DOES have. The question was whether Forth "encapsulated more of computer science" than C. The capability to add a nice type system or OO constructs to Forth does not count in this regard. It has neither of these things built in and thus does not "encapsulate" them. It matters not whether C's type system is any good. The point is that C has addressed the issue and Forth has not. -- Bill <bouma@cs.purdue.edu>
adam@visix.com (03/05/91)
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. Language design courses generally |> involve defining some sort of Pascal subset, and then writing a compiler |> for that subset. Computing theory is not happy with languages that are |> not constant in their definition... There may be a comment in A text, but |> Forth's "strong points" are NOT seen by language theorists as theoretically |> interesting. #define Incredibly-Arrogant-Tone-Slightly-Ameliorated-By-Humorous-Comment Quite frankly, I think typical language theorists are interested in the wrong things. |> What "new" control structures have been created in Forth? I'm not sure |> Forth has introduced ANY new control structures... I've recently concluded that control structures suck. They focus your attention on nitpicky little details of tests and switches instead of the higher level tasks you want to do. Structured programming states that GOTO's are evil because they are used to implement many different kinds of loops and branches. It is better to name the higher level constructs and use them directly. Why don't we take this reasoning further? What are loops used for? (1) Applying an action to all members of a set. (2) Sequencing similar actions. (3) Filtering a stream. These uses are focused around data types: set, sequence, stream. In (1), our iterations equal the size of the set, but we don't care about the execution order. In (2), we have a fixed set of actions for which order matters. In (3), we have an arbitrary length (perhaps infinite) sequence of actions. Why denote all of these with the same construct? Why not provide Sets, Sequences, and Streams, each with a corresponding "execute_over" operation? Think APL. Think Lisp. Think Unix. Similarly, conditionals and switches are used primarily to map sets of values to sets of actions. I suspect all control structures can be "hidden" this way. I suspect you could program in a style that uses control structures as rarely as structured programming uses GOTO. |> The people that spend their time writing about LALR(1) parseable languages |> don't want to KNOW about Forth... LALR parsing sucks. As Mitch Bradley pointed out, syntax sucks. (Okay, he was more polite.) Lisp manipulates programs easily because it doesn't have to translate the damn representation before and after every manipulation. All through my compilers course I was thinking "what a waste of time." This is not to say that I think Forth is a great language for theory. Forth is a practical language, not theoretical. But precisely for that reason, Forth hints at questions that theorists forget to ask. The theory of control structures is interesting, but what good is it? (Most control details should be abstracted away.) The theory of parsing is interesting, but what good is it? (If you want your programs to look like algebra or natural language, you have to parse them. But parsing costs power and efficiency.) Theorists follow their interests, often without considering applications (nor should they). Compiler theory is supposed to be all about productivity, but a compiler theorist is buried too deep to ask, "should I really be using a compiler?" When I'm trying to maximize my productivity, a lot of computer science looks like right answers to the wrong questions. Adam
UNBCIC@BRFAPESP.BITNET (03/06/91)
> I've recently concluded that control structures suck. They focus your > attention on nitpicky little details of tests and switches instead of > the higher level tasks you want to do. Hehehehehe. I'll show you that you are wrong! > Structured programming states that GOTO's are evil because they are > used to implement many different kinds of loops and branches. It is > better to name the higher level constructs and use them directly. Not at all. Structured programming let you use GOTO to simulate IF THEN ELSE, WHILE and or any higher level control structure. But you can use GOTO in other ways. > Why don't we take this reasoning further? Ok, let's reinvent the weel (your arguments were used sometime ago... 196X). > What are loops used for? LOOPs doesn't mean CONTROL STRUCTURES! > (1) Applying an action to all members of a set. > (2) Sequencing similar actions. > (3) Filtering a stream. > These uses are focused around data types: set, sequence, stream. In > (1), our iterations equal the size of the set, but we don't care about > the execution order. In (2), we have a fixed set of actions for which > order matters. In (3), we have an arbitrary length (perhaps infinite) > sequence of actions. > Why denote all of these with the same construct? > Why not provide Sets, Sequences, and Streams, each with a > corresponding "execute_over" operation? Yes, iterators. They exist in Functional and Object Orientation Paradigms. Sometimes they are not efficient, by the way. > Think APL. Think Lisp. Think Unix. I didn't understand the last. Anyway, for the first two: Think Functional Paradigm! And Think OOP because there you have this too... > Similarly, conditionals and switches are used primarily to map sets of > values to sets of actions. > I suspect all control structures can be "hidden" this way. I suspect > you could program in a style that uses control structures as rarely as > structured programming uses GOTO. No IF's? How can you do that? LISP can't... APL have IFs too. I know the operation that selects part of the vector depending upon other vector of zeros and ones. But what to do is so important as with what to do. > All through my compilers course I was thinking "what a waste of time." Now, that is important. If you don't want to program in an enviroment. (Not a joke) > This is not to say that I think Forth is a great language for theory. > Forth is a practical language, not theoretical. But precisely for > that reason, Forth hints at questions that theorists forget to ask. Some of them, yes. Most of them, probably. All - NO WAY. But you cannot expect that many theorists do the right thing -- statistically there is less brilliant people than than the commom ones. > The theory of control structures is interesting, but what good is it? > (Most control details should be abstracted away.) Iteratio is a control structure, if you don't know. Control structures makes the program do things in a non-sequencial way. Calling procedures is a control structure, repeat many times is a control structure, and it doesn't matter if your LOOP is hidden or not. You HAVE to specify an iterator, don't you? > The theory of parsing is interesting, but what good is it? > (If you want your programs to look like algebra or natural language, > you have to parse them. But parsing costs power and efficiency.) Ok. But the theory applies to NL Interfaces too, not only programming languages. > Theorists follow their interests, often without considering > applications (nor should they). Compiler theory is supposed to be all > about productivity, but a compiler theorist is buried too deep to ask, > "should I really be using a compiler?" > When I'm trying to maximize my productivity, a lot of computer science > looks like right answers to the wrong questions. Yes. That's why there is the word vanguard. > Adam (8-DCS) Daniel C. Sobral UNBCIC@BRFAPESP.BITNET
bouma@cs.purdue.EDU (William J. Bouma) (03/06/91)
This a reply to Clyde Phillips reply to Chris Browne. It is
mainly an attempt to get him to clarify a number of cryptic
remarks he made in that post.
In article <1991Mar4.143704.13146@cbnewse.att.com> cwpjr@cbnewse.att.com (clyde.w.jr.phillips) writes:
>Are CS people only interested in "language Design"? No wonder they don't
>respect FORTH, it says they have no clothes...
Basically, "CS people" are interested in Computer Science. Language
Design is ONE are of interest for what should be obvious reasons. I
am surprised that you would think it the ONLY area as several others
are listed below in plain sight.
I am not sure what you mean by the "no clothes" bit?
>Is this the heart of CS?
>
Browne> Computing theory is not happy with languages that are not constant
>
>Is this the heart of CS?
What is "the heart of CS"?
Browne> Forth will be interesting to people into architecture design -
This was the only place I found disagreement with Browne's post.
I am not convinced Forth has anything new to contribute in this
area. If so, what exactly?
Browne> it does lots of neat stuff
>
>Thanks.
You had nothing to do with it!
Browne> Yes, you can define new "operations"/procedures/words. That's been
Browne> possible since FORTRAN. Subroutines are hardly a new concept.
>
>But ones that work in hardware are.
Huh?
>Ever see the cryptic C contests?
What does that have to with anything? In cryptic contests
people are TRYING to be cryptic!!
Browne> What "new" control structures have been created in Forth? I'm not sure
Browne> 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?
What? The "point" has always been to find a reason why Forth would
be of any interest to CS. Browne is simply stating it has done
nothing new in this particular area, thus we can dismiss it (area) as
a possibility.
Who is this "we"? Am I included? Is Browne?
One of the problems here is you are reading Browne as though
he is not included in the "we".
>Neither in C so why a bias?
Who is biased over control structures?
>I guess I should have looked at your bottom line...
I think the problem is you are looking only at single lines and not
thinking about the large picture. Browne is just telling you how
CS probably sees Forth. Don't take it out on him, it isn't his
fault. You think it's wrong, tell us why, we don't read minds.
--
Bill <bouma@cs.purdue.edu>cbbrowne@csi.uottawa.ca (Christopher Browne (055908)) (03/07/91)
In article <13693@medusa.cs.purdue.edu> bouma@cs.purdue.EDU (William J. Bouma) writes: > > This a reply to Clyde Phillips reply to Chris Browne. It is > mainly an attempt to get him to clarify a number of cryptic > remarks he made in that post. Minor question: Which "him" is to clarify? I think you mean Clyde... I'll try do some clarification anyways... >In article <1991Mar4.143704.13146@cbnewse.att.com> cwpjr@cbnewse.att.com >(clyde.w.jr.phillips) writes: >>Are CS people only interested in "language Design"? No wonder they don't >>respect FORTH, it says they have no clothes... > > Basically, "CS people" are interested in Computer Science. Language > Design is ONE are of interest for what should be obvious reasons. I > am surprised that you would think it the ONLY area as several others > are listed below in plain sight. Hey, if we're talking about the way Forth is put together, then that's certainly "Language Design." The BEAUTY of Forth is that you are always in the process of redesigning the language (i.e. - the language of the application - not usually the ENTIRE Forth language). The people reading this group are CERTAINLY interested in this area. And it's worth contrasting Forth Language Design with the classical CS forms of language design. >Browne> Computing theory is not happy with languages that are not constant >> >>Is this the heart of CS? It's perhaps not the MOST important part of CS (I'm not sure what IS the most important area of CS), but it's certainly at the heart of computing theory. You've got to have some way of communicating to the computer just what you want it to do. That's language, and language is undoubtedly of great importance. >Browne> Forth will be interesting to people into architecture design - > > This was the only place I found disagreement with Browne's post. > I am not convinced Forth has anything new to contribute in this > area. If so, what exactly? Well, there's certainly been some work lately on Forth chips. It looks like they may actually be good for things other than "merely" running Forth. (The REST of the world wants to run things like C, Fortran, Pascal, and minor mods to the Forth chips make 'em good for these other languages.) People have used Forth ideas to make the processors faster. I think that qualifies as "architecture design." >Browne> What "new" control structures have been created in Forth? I'm not sure >Browne> 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? "us guys"? That seems a little mean... The point was that the author I was apparently originally responding to made a statement about "control structures introduced through Forth." My point was that there don't seem to really be any uniquely introduced through Forth. > What? The "point" has always been to find a reason why Forth would > be of any interest to CS. Browne is simply stating it has done > nothing new in this particular area, thus we can dismiss it (area) as > a possibility. Exactly. > Who is this "we"? Am I included? Is Browne? > One of the problems here is you are reading Browne as though > he is not included in the "we". I too wonder who "us" and "you/them" are supposed to be... >>I guess I should have looked at your bottom line... > > I think the problem is you are looking only at single lines and not > thinking about the large picture. Browne is just telling you how > CS probably sees Forth. Don't take it out on him, it isn't his > fault. You think it's wrong, tell us why, we don't read minds. I guess I'm a criminal because I've been studying CS over the years... The point of the article was to supply SOME picture on how "real CS" people see (or more likely, don't see) Forth. I've spent enough years around such people/places that I have SOME insight on the issue. I don't particularly want to give offense, or start a flame war, but I don't appreciate being blasted for HAVING some CS education. To the Forth world, spending time doing CS seems to be a black mark. I think that not all of CS has value, but that some of it DOES. Forthers try to look at things very pragmatically - that's where the language came from. Forth started as a hack to control telescopes, and then grew. Compared to Forth, Fortran started as a language to simplify programming scientific computations. The reasons FOR the computations were pretty "theoretical", but the language's design has always been pretty pragmatic. C was developed in a research laboratory to help design operating systems. There's certainly a lot of "theory" and NON-pragmatic features there. They had opportunity to say "What would we like?" as well as Forth's "What do we need MOST?" The Pascal family of languages grew up in the academic environment, and thus are "Conceptually Beautiful," at the expense sometimes of being practically useful. All of these different sources of computer languages have had SOME worthwhile insights. Some of these insights may be worth patching into Forth. One advantage to using Forth is that it is possible to patch features in in reasonably attractive ways. Originally, Forth did not have a CASE statement. It was fairly straightforward to add it for those applications that could use CASEs. That's not possible for these other languages. In the more strongly typed languages, it's almost impossible to hack in any MAJOR changes. In Forth, I can add operations that use "algebraic" notation rather than Reverse Polish. In Modula-2, it's just impossible. I feel that we should look at some of the "neat features" that get added to other languages, and see if there's a good way to put the best of them into Forth. In this way, it's certainly a GOOD THING to look at what "Computer Science" is doing. -- Christopher Browne cbbrowne@csi.uottawa.ca University of Ottawa Master of System Science Program
adam@visix.com (03/08/91)
Okay, I guess I should explain myself more carefully. I stated that structured programming considered GOTO's evil, primarily because I wanted to use that example for an analogy. I won't argue about whether GOTO's have legitimate uses. I won't argue about whether the definition of structured programming necessarily considers GOTO's evil. I know that not all control structures are loops; e.g. CLU and Ada have exception handling. I used loops as a common example. I only concluded recently that "control structures suck," so I am not prepared to demonstrate equivalents for every existing control structure, and so I wrote "used primarily", and "I suspect." I do not think all theorists forget to ask the right questions. I do not think my questions are the ones theorists have to ask; I do not think that theorists are doing the wrong thing. > Theorists follow their interests, often without considering > applications (nor should they). ^^^ ^^^^^^ ^^^^ I do think that techniques like parsing, which may be very well understood theoretically, are not necessarily the best way to improve my productivity as a programmer (unless I do Natural Language). > Ok, let's reinvent the weel (your arguments were used sometime ago... 196X). I don't understand the purpose of this comment. Are you claiming that people already program in the style I suggest? I don't find this in the code I have seen, except for APL, some (repeat: some) Lisp programs, and UNIX one-line command scripts. I wouldn't claim to have invented this wheel; APL, Lisp, and UNIX are examples. I should also say that my train of thought was started by the "Minimizing Control Structures" chapter of Thinking Forth. But wheels that have been invented still need to be used. I also can't tell what you mean about my arguments being used back in 196X. I'm not even sure if you might have misunderstood my argument. References would help. > I didn't understand the last. (UNIX) Briefly, UNIX's pipe operator allows you to construct surprisingly sophisticated one-line command sequences, without conditionals. Please don't ask me to explain in detail; any good UNIX book will do. > Anyway, for the first two: Think Functional > Paradigm! And Think OOP because there you have this too... Functional programming is about evaluation and avoiding side-effects. These are separate issues from how often the keyword "IF" appears in your program. And, Goldberg and Robson's _Smalltalk-80_ contains neither use nor mention of the programming style I suggest. > No IF's? How can you do that? LISP can't... APL have IFs too. : : > Iteratio is a control structure, if you don't know. Control structures makes >the program do things in a non-sequencial way. Calling procedures is a control > structure, repeat many times is a control structure, and it doesn't matter if > your LOOP is hidden or not. You HAVE to specify an iterator, don't you? I just realized what I should have said in the first place. Every line should be a basic block. A basic block has one entry point and one exit point. In languages like C, since a function is the unit of decomposition, it is only required that functions be basic blocks. Since Forth encourages a finer decomposition, it suggests that we can make basic blocks smaller. Smaller basic blocks also provides enormous benefits for traditional compilers; smaller basic blocks makes programs easier to reason about, and therefore easier to optimize, and also easier to parallelize. Adam
schmidtg@iccgcc.decnet.ab.com (03/11/91)
In article <13699@medusa.cs.purdue.edu>, bouma@cs.purdue.EDU (William J. Bouma) writes: > In article <3554.27d21955@iccgcc.decnet.ab.com> schmidtg@iccgcc.decnet.ab.com writes: >>meaning is imparted not by syntax, but rather by program structure, > > Can you clarify the difference? I think our discussions up to now > have all been pretty consistent about what syntax means. The way I > see it the structure is the syntax. Perhaps I just don't follow > what you mean. Clarity vs. meaning. Adding additional syntax to FORTH might improve the clarity of FORTH code, but would not add to the expressive power of the language. This is to be contrasted with a highly specialized language such as YACC, where the expressive power of the language IS a direct result of its syntax. >>it interesting that some of the current trends towards "object oriented" >>languages and "rapid prototyping" have been enjoyed by the more experienced >>FORTH programmers for years. > > "object oriented" programming had been going on for a long time > before so called "software engineers" jumped on the bandwagon and > made the term popular. That is not unique to Forth programmers. It > easy to look back now and say Forth was ahead of its time in this area. > But why didn't someone publish about constructs in Forth to support OOP > before any of the OO specific languages had been built? > I don't honestly believe that FORTH "anticipated" OOP. I would say that FORTH was ahead of its time in that with FORTH's extensibility, one can easily extend the language to encompass OOP. True, OOP can be done in almost any language, but with FORTH, it can be seamlessly integretated into the language. With FORTH, I don't need to throw everything out, and invest in a smalltalk or c++ compiler to effectively take advantage of OOP. (refer to Dick Pountain's book, "Object Oriented FORTH") >>LISP has gravitated to the AI community and FORTH has gravitated to the >>embedded processor arena (I still consider FORTH to be an excellent "general >>purpose" language and I am sure many would say this about LISP too). > > I do not think Forth is a very good general purpose language. The > reason is same one (I believe) that has kept and will keep Forth from > being accepted generally. The lack of a type system is what has kept > Forth down. A language that deals only with characters and integers > is a joke. It is no coincidence that Forth gravitated to the embedded > processor area, they don't need to deal with anything besides integers > and characters. Forth will not be accepted academically or be useful > generally until it adopts a general consistent way to deal with a wide > variety of types. > FORTH is an excellent general purpose language for just these reasons! FORTH provides one with the tools to create more specialized tools which are useful to solve a given problem. Try adding a new control structure to 'c'! Traditional compilers just make too many assumptions about what it is you want to do. If additional data types are required for your application, FORTH allows you to easily create them. Perhaps FORTH's expressive power is not for everyone, but when used with discipline, allows the creation of higher level languages which are custom tailored to your specific applications. >>The point that I am trying to make is that FORTH has not received the >>widespread acceptance that it deserves, it has had no "Academic sugar daddy" > > 8^) Perhaps. Perhaps it just isn't that deserving of attention from > people who aren't tring to interface to hardware or aren't limited to > 64K of memory. Or is it that concepts such as "rapid prototyping" and "extensibility" aren't "deserving of attention" unless we refer to them in a language like smalltalk, which originated in a research laboratory? -- ============================================================================= Greg Schmidt -> schmidtg@iccgcc.decnet.ab.com ============================================================================= "People with nothing to hide have nothing to fear from O.B.I.T" -- Peter Lomax ----------------------------------------------------------------------------- Disclaimer: No warranty is expressed or implied. Void where prohibited. =============================================================================