orr@cs.glasgow.ac.uk (Fraser Orr) (09/23/88)
In article <810002@hpmtlx.HP.COM> adam@hpmtlx.HP.COM ($Adam Kao) writes: >Fraser, the reason I like forth is because it's INCREMENTALLY COMPILED. >This means I get the fast turnaround of an interactive system (think-edit- >run vs. think-edit-compile-run) while generating code that runs almost as >fast as compiled code. [Reasons about exploration and fast trun around deleted, since they say basically the same as above ] There is of course no reason why a preprocessed language cannot be incrementally compiled. In fact no reason why it cannot be interpreted. E.g., the equivelent of forth's ';' could take the preceding definition preprocess it and then make a definition. All of these advantages need not be lost by using a preprocessor. Thus I think your conclusion ... >I think this and the other reasons that have already been posted are excellent >justification for rejecting a preprocessor. > is unjustified. >Adam Regards, ===Fraser (PS sorry I couldn't reply to your mail Adam, I couldn't find a route)
hjm@cernvax.UUCP (Hubert Matthews) (09/27/88)
One problem with pre-processors is error handling. Consider a PP that translates Ratfor into FORTRAN IV. Whilst the program is running, a division by zero occurs and an error is reported. The line number returned is the number of the line that caused this exception, but in the FORTRAN program and not the Ratfor program. The user then has to examine the PP output in order to determine the correspondance between his view (the Ratfor) and the PP's view of his code. In an extensible language, the error line number refers directly to the user's code and not to an intermediate representation. Do you prefer an error message that says "div by zero in line 364" or "div by zero at PC=00247AFC"? Hubert Matthews -- Hubert Matthews
orr@cs.glasgow.ac.uk (Fraser Orr) (09/28/88)
In article <837@cernvax.UUCP> hjm@cernvax.UUCP (Hubert Matthews) writes: >One problem with pre-processors is error handling. Consider a PP that >translates Ratfor into FORTRAN IV. Whilst the program is running, a division >by zero occurs and an error is reported. The line number returned is the >number of the line that caused this exception, but in the FORTRAN program and >not the Ratfor program. This is neither necissarily true, nor true in practice. My C++ compiler (which is a preprocessor for C) produces error messages in terms of the original program, not the produced program. In fact in all the months I've been using this program I have never had to look at the code produced by the preprocessor (which is just as well since it is pretty unreadable.) By the way, I thought ratfor had evaporated into the mists of UNIX history.... ===Fraser