d88-bli@nada.kth.se (Bo Lindbergh) (02/09/90)
In article <10865@claris.com> drc@claris.com (Dennis Cohen) writes: ... >I think that a better solution for such simple errors would be one that was >in one of the first Pascal compilers I ever used (1979). The University of >Wisconsin's Univac 1100 compiler gave a warning message with the context and >continued to compile, treating the source as though the semicolon were there. >If Fischer and LeBlanc could do that on a Univac 11 or 12 years ago, it seems >that we should have compilers that do that now. Some errors were non- >recoverable; however, I've missed that "friendliness" in every compiler I've >used since then. The Microsoft Pascal compiler for MS-DOS does this too... I suppose this doesn't help you very much. ;-) Anyhow, I miss this feature too. It isn't that hard to extend the syntax to include common errors like missing semicolons or semicolon before 'else', so why isn't it done more often? Are compiler writers just lazy? --
hpoppe@bierstadt.scd.ucar.edu (Herb Poppe) (02/10/90)
In article <2899@draken.nada.kth.se> d88-bli@nada.kth.se (Bo Lindbergh) writes: >... >Anyhow, I miss this feature too. It isn't that hard to extend the syntax to >include common errors like missing semicolons or semicolon before 'else', so >why isn't it done more often? Are compiler writers just lazy? No, they are just trying to keep programmers from becoming lazy ;-). -- Herb Poppe NCAR INTERNET: hpoppe@ncar.ucar.edu (303) 497-1296 P.O. Box 3000 CSNET: hpoppe@ncar.CSNET Boulder, CO 80307 UUCP: hpoppe@ncar.UUCP
edgar@shape.mps.ohio-state.edu (Gerald Edgar) (02/10/90)
Long ago I used IBM's PL/I compiler on a 360-type machine.
It had this feature: when there is a syntax error, the compiler
"guesses" what was intended, and goes on. However, my experience was
that it always guessed wrong ...
--
Gerald A. Edgar
Department of Mathematics Bitnet: EDGAR@OHSTPY
The Ohio State University Internet: edgar@mps.ohio-state.edu
Columbus, OH 43210 ...!{att,pyramid}!osu-cis!shape.mps.ohio-state.edu!edgarleipold@eplrx7.uucp (Walt Leipold) (02/13/90)
Though it's taken a lot of heat, the autoformatting editor is one of the many things I love about Think Pascal -- it warns you of syntax errors while you're entering your code, not during compilation. Of course, it _does_ take some getting used to... -- "As long as you've lit one candle, Walt Leipold you're allowed to curse the darkness." (leipolw%esvax@dupont.com) -- -- The UUCP Mailer
murat@farcomp.UUCP (Murat Konar) (02/15/90)
In article <1990Feb13.152922.26555@eplrx7.uucp> leipold@eplrx7.UUCP (Walt Leipold) writes: >Though it's taken a lot of heat, the autoformatting editor is one of the >many things I love about Think Pascal -- it warns you of syntax errors >while you're entering your code, not during compilation. Of course, it >_does_ take some getting used to... I LOVE the auto-formatter!!!!!!!! I really miss it when in MPW or THINK C. Infact, I routinely use THINK Pascal to print out MacApp code. It's a lot easier to read with all the keywords in bold. I do wish you could turn it off just to look at normal text files though. I hate having to switch out to a text editor to look at non-pascal code. -- ____________________________________________________________________ Have a day. :^| Murat N. Konar murat@farcomp.UUCP -or- farcomp!murat@apple.com
minich@a.cs.okstate.edu (MINICH ROBERT JOHN) (02/16/90)
> I LOVE the auto-formatter!!!!!!!! I really miss it when in MPW or THINK C. > Infact, I routinely use THINK Pascal to print out MacApp code. It's a > lot easier to read with all the keywords in bold. I do wish you could turn > it off just to look at normal text files though. I hate > having to switch out to a text editor to look at non-pascal code. > murat@farcomp.UUCP -or- farcomp!murat@apple.com For editing raw text files, I use the *Edit DA (where * = appleMark) that came iwth THINK Pascal. It doesn't line wrap and defaults to monaco. It's also great for text files from non-Mac sources where spacing sometimes counts for tables, etc. It's also VERY convenient in other apps. Also, it has now known (to me) limit on filesize, has a cheap-but-good search command, and is (also to me) free. Robert Minich minich@a..cs.okstate.edu Oklahoma State University Disclaimer: I back this disclaimer fully. (That is, I don't.)
wilkins@jarthur.Claremont.EDU (Mark Wilkins) (02/18/90)
One question which has had me guessing for a while is this: Why is it that some compilers use the error message "<symbol> inserted" when they really mean that there is a missing symbol and you must insert it yourself? Doesn't "<symbol> missing" or "<symbol> not inserted" (1/2 :-)) make more sense? Just a thought. When I was learning to program I had an awful time figuring out what it meant. -- Mark Wilkins wilkins@jarthur.claremont.edu
pete@ics.uci.edu (Peter Miguel Oleary) (02/19/90)
In article <4464@jarthur.Claremont.EDU> wilkins@jarthur.Claremont.EDU (Mark Wilkins) writes: > > One question which has had me guessing for a while is this: Why is it >that some compilers use the error message "<symbol> inserted" when they >really mean that there is a missing symbol and you must insert it yourself? "<symbol> inserted" means, roughly: "I was expecting to see a <symbol> at this point but I didn't so now I am going to have to insert a <symbol> here so that I can continue parsing". Pick up any good book on compiler design and look for the chapter on error recovery. Pete O'Leary.