Path: utzoo!utgpu!attcan!uunet!husc6!think!bloom-beacon!tut.cis.ohio-state.edu!mailrus!cornell!batcomputer!olson From: olson@batcomputer.tn.cornell.edu (olson) Newsgroups: comp.lang.forth Subject: Re: Forth "Pre-Compiler" Message-ID: <5768@batcomputer.tn.cornell.edu> Date: 4 Aug 88 05:25:27 GMT References: <8807221513.AA05347@jade.berkeley.edu> <3d7612e1.13370@dow4.engin.umich.edu> <1533@crete.cs.glasgow.ac.uk> <5703@batcomputer.tn.cornell.edu> <1557@crete.cs.glasgow.ac.uk> Reply-To: olson@tcgould.tn.cornell.edu (olson) Organization: Cornell Theory Center, Cornell University, Ithaca NY Lines: 143 >>How would you compute if the process of calling proceedures had zero overhead? In article <1557@crete.cs.glasgow.ac.uk> orr@cs.glasgow.ac.uk (Fraser Orr) writes: >In article <5703@batcomputer.tn.cornell.edu> olson@tcgould.tn.cornell.edu (olson) writes: >>I was going to let this slide, but given the tone of this posting and the >>next posting (about the Novix chip) by Mr Orr ... >>Mr Orr, >> Don't you think you are being just a little too viscous? >> Disagreement is wonderful, but only if all participants refrain >>from attacking each other. (Another "wonderful" "American" discovery) > >My appoligies if you found my remarks offensive Mr Olsen. To be honest ^o >I expected an erudite net'er like yourself to be able to recognise >good humoured sarcasm when you saw it. Oh. Well, sorry for missinterpreting the tone of your comments. I must confess that your remarks fell on my eyes as those of one with an axe to grind against all aspects of forth, apparently blindly. Glad to hear this is not the case. [... good comments about problem solving deleted ...] >>Thus one might argue that the advantage to forth is that it lets you >>move from thinking to thinking and experimenting. > >This is the crux of the matter, can you justify this statment. Possible we have different styles of problems in mind. The problems I deal with have few direct antecedents. At the start I think about the nature of the problem, and usually I come up with several viable approaches. How do I pick one to work on? Well, 6 or 7 years ago, I would just sit and think more. This resulted in several years of very slow progress on my research. The method I am trying now, is when thinking begins to have diminishing returns for me, then I go and "play". This means try something and see what the results are. Play requires highly interactive experimenting. Every thing is variable, including the problem statement and what goes in to it. After enough play, I have learned enough, made enough observation, tried enough experiments, that I can begin making hypothesis. Eventually playing gives diminishing returns so I go back to thinking. After many cycles the problem becomes well enough defined in my mind that it can be stated and evaluated in theorem proof form. But until then I find play/experiment essential. For me the key to making headway on a problem is knowing how and when to apply one style or the other to the problem at hand. Further, which of several approaches is "best" frequently depends on how I hope to extend the problem after the immedeate concerns are addressed. I find that solutions to my problems are usually a language for discussing the issues of the problem. I find that languages such as C,FORTRAN,Pascal,... tend to actively inhibit my efforts to create such languages. I find that forth does not. One might argue that the proper medium for creating languages is a language generator (eg YACC/LEX). I would argue that that is what Forth is. Further to develop a useful language you must use it, play with it, experiment with it. I feel that forth supports this aspect well. Well, I'm wearing out. I hope this speaks to the point some what. Let me remark that I find a lot of flaws in Forth. I have a project in the wings for taking the forthness of forth and implementing it better, to demonstrate and improve the good points of forth. Or maybe it will show the converse. >... >>How would you compute if the process of calling proceedures had zero overhead? >Are you trying to say forth has zero overhead for calling procedures? No. Seems as though the context intruded more than I thought it would. (oops) I meant the question to be taken independent of the forth context. >Am I completely missing your point here? I'm probably being obscure. I have seen and even written C code, that for the sake of speed and clarity have used a fair number of macros. The clarity could have been achieved by using proceedure calls but the over head of making a C procedure call (creating the stack frame and all) was deemed to be too much. I prefer forth's way in this case. Also C programs can be found that have switch statements with substantial code blocks at each case point. Forth's style would be to make each block a proceedure and at each case point only a proceedure call would occur making the code more readable one hopes. Admittedly this is in some sense a matter of style. But it seems to me that the styles fostered by a language and it's community are as important as the language itself. Forth fosters "factoring" via the preception of low overhead for invoking a word, C does not via the perception of a modest cost for invoking a proceedure. Style(?). This was the thrust of my question. But I am curious if from sort of first principles thought the question produces ideas at odds with existing languages? That is why I asked it the way I did. When I say I program in C (FORTRAN, ..) in Forth style what I mean is that I factor thing as much as possible. (Then if performance demands, I put some of the pieces back together.) Is this what other people mean by working in the forth style? >... >>And that in some sense the Unix "philosophy" is very forth like. > >Justification? The Unix "philosophy" as I understand it is to write your programs in such a way that they do one simple task and that they cooperate with each other so that they can be combined into more complex tasks. This is a good explanation of the the forth idea of factoring. Maybe the confusion here is that for me Forth is only loosely related to it's implementations. >... > >I feel that gorups like comp.lang.forth can become very narrow minded >(the group has a very narrow set of discussion topics, I'm not trying to >suggest that the participants are narrow minded of course!) It is good >to discuss the things that other people are doing, in a way that is >relevant to your subject of interest. As I mentioned previously I have >never understood why Forth'ers are not prepared to use parsers so that >their code is more readable. Lets see what we can learn form each other >instead of indulging in mindless "I think my language is better than yours" >wars. I accept that Forth is fast on Forth chips, I also assert that >C or Pascal are easier to program in. What can I learn from you, >and what can you learn from me? >==Fraser Orr ( Dept C.S., Univ. Glasgow, Glasgow, G12 8QQ, UK) Nicely said. I disagree at several points. 1) parsers make code more readable. ??? I can't agree. 2) I would venture that "forth chips" 3) Pascal and C are easier to program in ??? I can't agree. I do agree that we should learn from each other. I intend to barrow every good idea I have ever come in contact or ever will. Incidently forth is one of the few systems that makes it easy to add on a good language feature to the existing language. For example it is very hard for C to learn from ICON. I have found C, etc useful because by being static in syntax they have taught me how discover both the good points and the limit to a particular syntax. For me it is now time to go beyond this. I need to be able to add to the good pieces I already have. To me forth (or my rendition of forth (one of forths weakness, no?)) is the best tool I have found so far building languages. For example I think forth offers me the best scheme for merging C++ and Icon. Now I agree that these things can not be done haphazardly. And with out a lot of self dicipline it is easy to make a mess in forth. But it can also do more within its frame work than anything else I know. This is vague. Give me a couple of years. Then I will be in a position to show you by example what I mean. Or I will have learned by experimenting that this approach is not viable. Todd Olson olson@helios.tn.cornell.edu