orr@cs.glasgow.ac.uk (Fraser Orr) (09/06/88)
I got in this morning and read the news. There were twenty articles in c.l.f mostly in response to my articles of last week. There were many interesting points, many useful comments, many stupid and cheap jibes and many replies that clearly missed the point of the original poster. Anyway, I would love to reply to all your contributions but, unless someone will give me a job as a full time c.l.f poster :->, I haven't the time. I'll reply to David Weinstein's article on preprocessors, and hopefully cover some of the useful points you have brought up in critisism of my suggestion. In article <4162@juniper.uucp> olorin@juniper.UUCP (David Weinstein) writes: >Here are the reasons why I don't want to use a pre-processor to write Forth >code: > >1) Debugging...debugging code generated by preprocessors is sheer hell! Not if you use a symbolic debugger it isn't. (raw opinion approaching) In fact I would say it was easier since you clearer programs are more debuggable programs. > >2) Efficiency...code generated by a preprocessor will not be as efficient >as the code I write myself. We've dealt with this question at length before. Perhaps by the very low level control you have in forth you could save a few micro seconds here and there (probably a lot less than you think though, if you produce your final product with an optimising compiler), but you can save huge amounts by using a higher level language allowing the programmer to see what is going on better, and thus allowing algorithmic optimisations (rather than picky little implementation optimisations.) >3) Readability...I really don't want to even have to look at the code being >generated by the preprocessor. Neither do I (any more than I want to read raw forth. That is why a necessary part of any preproc package would be various symbolic tools to save you having to do this. >4) Code level. The use of the features you mentioned (strong typing, parameter >lists, etc) remove my primary reasons for using Forth, the ability to write >code at all levels from truly low to truly high. Since I do almost all of my >work under Unix, if I have to put up with parameter lists and "almost" >languages, I might as well use C. > I've heard a lot of wishy-washy "i don't like" talk, particularly about param lists. If any of you out there are scientists, then it would be useful f you could give good reasons for your dislike. I've told you in some detail why I think RPN and the stack model are not so good. David has tried to do so here, he says "... write code at all levels from truly low to truly high". Why do you believe that a type system would prevent you writting low level code though? By low level I guess you mean controlling devices but there are many type systems that allow type secure control of devices. Or do you mean having an array of bytes and quickly clearing them by treating it as an array of words (only doing half the memory accesses)? Type systems won't allow this sort of thing, and for a very good reason - portability, and clarity (oh, thats two very good reasons:^) James N Strich posted an excelent article on this subject, so I don't feel the need to say any more. >5) I hate parameter lists. Ah, the joys of logic....;^> > >6) Well written Forth, I mean the high level stuff...should look like pseudo >code...I can't do that with the preprocessor getting in my way. Sorry Fraser, >but the top level *should* hide the parameter passing. The top level should >make the algorythm perfectly clear, at lower levels I can look for the pure >and simple mechanics of parameter passing. The way you say this is as if it is a great revelation to me. I agree. Top level code should look like pseudo code. And it should hide all the unnecessary param passing. I don't agree though that it sould hide all the params, because the thing that I am interested in when reading the top level of a program is the data flow around the program. Now I agree that pipe like constructs are good (where you see the data at both ends, and there is well defined transformations at each stage) but this can be simulated in prefix and infix languages by function composition. Now I agree that this is not as good as, say the syntax for UNIX pipes, because the operations are the wrong way round, but since were building a preprocessor, we could introduce a pipe type operator that was infix with a well defined meaning. (e.g. a (a-list) | b (b-list) | c (c-list) is equivelent to (in prefix syntax c ( b ( a (a-list), b-list), c-list), which is of course not nearly as nice) Why do you need the param lists here? Because it is necessary to feed in extra data at various points in the pipeline. Now before there is a rash of postings saying that this pipe syntax is just postfix with '|' in between the words. I know. The point is though that this sort of thing fits in nicely and neatly with {pre,in}fix notation. >-- >Dave Weinstein There is one other thing I would like to answer. this is a paragraph from Don Hayes posting. >Reading Frazer Orr's comments has brought to mind other questions. >Why does he keep dwelling on a FORTH compiler? Is he perhaps writeing >one that he hopes to sell? Or is he just anti-FORTH because he cannot >comprehend the usefullness of being able to tailor a language to fit >ones needs? Firstly, no I am not writting a forth precompiler to sell (and I resent the suggestion). Secondly I am not anti forth. I just want to see forth put into the niche in which it would be most useful, the code generated by a compiler. Thirdly I can well comprehend why you think it is useful to be able to tailor a language to fit your needs. I think though it is much better to build a language that suits most people's needs and then define this as a standard. Or do you not believe standards are important? (Hey man, they cramp ma style...:^>) Regards, Fraser.