/* TEACH MISHAPS A. Sloman Nov 2011 CONTENTS - (Use g to access required sections) -- INTRODUCTION: TYPES OF PROGRAMMING ERRORS (MISHAPS) -- Example of an mishap -- The structure of this file -- Make this your own file using ENTER name .... -- Another example : a command with faulty syntax -- More on syntactic errors -- Run-time errors -- Clear the output.p file -- What produces a 'run time' error? -- Further reading -- INTRODUCTION: TYPES OF PROGRAMMING ERRORS (MISHAPS) ---------------- This file gives a brief introduction to compile time errors (called 'mishaps' in pop11 error reports) and run time errors (also called 'mishaps'). It also explains how to rename a teach file so that you can save it as your own, with changes you have made. Most of this file merely introduces the format of teach files containing executable code, for practice with dealing with an error when the whole file is compiled. Your task is to fix the errors in the file, so that the whole file will compile, without error, and print out the special message at the end. The table of contents is near the beginning. You can go to it using the command ENTER g When developing programs you will need to know how to mark and compile a range of text in Ved, how to save your file, how to return to it later. This file will give you practice in doing those things. */ /* This section is inside one of the many "comments" in this file. Immediately after this comment ends there are four pop11 instructions that do not produce mishaps when the file is compiled followed by an instruction that does produce a mishap. See if you can add three more instructions that compile and run OK, when you attempt to compile the whole file by doing: l1 (That's lower case "L" followed by the numeral: 1). Try it. The "l" stands for "load": instructions are loaded into the compiler. The comments are all ignored. You will get a mishap message caused by a faulty instruction below. Come back here after that and read on. Some legal Pop-11 instructions follow: */ 99 + 100 => length([a list of words]) => 'Joining one string' >< ' to another' => 'Joining a string to a number: ' >< 9999 => /* Try adding at least three more instructions (before the line containing the start of the comment, indicated by '/' immediately followed by '*') Test your instructions by doing ENTER l1, as before. You should get the same mishap message as before produced by a faulty example below: ;;; MISHAP - NUMBER(S) NEEDED ;;; INVOLVING: 66 five If you get a new mishap message, caused by one of your commands, try to fix the command that produced it. Then check it by doing ENTER l1, and read on. */ /* -- Example of an mishap ----------------------------------------------- The next instruction produces a mishap. See if you can change it so that it does not produce a mishap. Test it with ENTER l1. If you succeed you'll see the printout from your command and get a mishap from another command further down the file. i.e.: ;;; MISHAP - mei: MISPLACED EXPRESSION ITEM When you get that error message read on. */ ;;; Alter this so that it does not produce a mishap ;;; There are many ways of doing that. 66 + "five" => /* -- The structure of this file ----------------------------------------- The file is a mixture of compilable pop11 code and commented out tutorial text. Because the file is compilable, at any time you can edit an example or a collection of procedure definitions and recompile the whole file (ENTER l1) However, the file includes some faulty commands that will interrupt the compilation of the file. Your task is to work through the faulty bits fixing them, till the whole file compiles and you are congratulated. Every time you see a mishap message in the output.p window, you'll need to look at the mishap line number and try to work out how to fix the line in question. Then you'll be able to compile everything up to the next mishap! This is invaluable preliminary practice for developing, testing, and debugging complex programs of your own later. */ /* -- Make this your own file using ENTER name .... ---------------------- If you leave this file, log out, and come back later all your changes will be lost because is a TEACH file and edits in such files are only temporary. (Why?) You can chose a name for your file. For example if you want to call it 'my_mishaps.p' do this: name my_mishaps.p If your ENTER key does not work, you can use CTRL-g NOTE: in linux you should not use a space in a file name, because spaces are 'delimiters' in commands, and can therefore cause commands to fail. Instead use the underscore "_" as above, or use a mixture of upper and lower case letters, e.g. name MyMishaps.p This style is sometimes called Camel-Case. Why? Choose a name and give the command to change the name. Use a name ending in '.p' for pop11 program files. Then get Ved to save the file on the hard drive, using the 'w1' command (wrote one file): w1 You should see on the status line, something like this: (/home/yourname/MyMishaps.p, 341 lines written) You can then quit the file using q Then come back to editing it again using this command given to linux: ved MyMishaps.p After returning, you can jump to line number 153 by giving the command 153 Or choose a different number to start at. */ /* -- Another example : a command with faulty syntax --------------------- An example follows: it is not legal pop11, so if you have already fixed all the earlier incorrect programs, compilation will get as far as this example. So now do: ENTER l1 RETURN */ ;;; A faulty instruction -- syntax error -- Found "]", expecting ")" sqrt( 99 ]) => /* That is a "syntactic error" generated while the program code was being compiled. That is sometimes called a "compile time error". Now delete or comment out that faulty line above. You can put the editor cursor on the line and use the key F4. (LINEDELETE). Try to insert another line in its place that you think should produce a syntactic error, to test your understanding of the syntax. Then compile the whole file, and examine the error message. NOTE: If your function key F4 does not delete a line you can still delete it by putting moving the Ved cursor to the right hand end of the line and then typing CTRL-U (sometimes abbreviated as "^U"). Practice by deleting these two lines using either F4 or CTRL-U Test line 1 for deletion Test line 2 for deletion Instead of deleting the faulty line you can 'comment out' the illegal line by using three semi-colons, as in: ;;; sqrt( 99 ]) => After removing or commenting out all the faulty commands above, try recompiling the whole file again: ENTER l1 RETURN. That will lead on to another error message, caused by a different faulty command, below. */ ;;; Try to fix this so that it does not produce a syntax error ;;; and instead prints out a sensible result sqrt[ 99 ]) => /* -- More on syntactic errors ------------------------------------------- Which of these do you think will produce a syntactic error? Why? You can compile each line separately by putting the text cursor on the desired line, then typing: ESC d sqrt ) [ 99 ]) => sqrt([ 99 ) => "the" "apple" => At this stage, don't try to understand everything in the error messages. They will become clearer later. You will meet more syntactic errors as you produce more complex programs. They are like playing wrong notes on a musical instrument. Another example of a syntactic error follows. Fix it, or delete it or comment it out. */ if length([peas and potatoes]) > 2 then 'That list is big ' finish => ;;; Try replacing 'finish' with 'endif', then test with ESC d ;;; Can you see what 'endif' does? /* -- Run-time errors ---------------------------------------------------- Read on when none of the pop11 commands earlier in this file produces an error when you do ENTER l1. If there's anything left above that is erroneous then you can go to the line whose number is specified in the error message, and fix the line, or delete it, then try compiling the whole file again: ENTER l1 The error message you now get should specify a line number bigger than the number you now see on the status line. I.e. the faulty line is lower down, below this point. The previous errors were COMPILE-TIME errors (syntax errors), which prevented a piece of program being fully read in and and run. But you can also get a RUN-TIME error (semantic error), as the next example will demonstrate. -- Clear the output.p file -------------------------------------------- By now your output.p file may have lots of printout from working commands and lots of error messages. You can clear all that junk by temporarily going to the output.p file (using ESC x), giving the 'ENTER clear' command then return to this file using the ESC x command. I.e. do these three steps, but BEFORE you give the clear command make sure that your status line says something like 'examining: output.p') x ENTER clear x That should leave you back here with an empty output.p file. Read on. -- What produces a 'run time' error? ---------------------------------- Here your program is compiled (translated to machine code), then run, and something goes wrong while the program is running: an operation is attempted that the Pop11 system does not allow, such as adding a number to a word, or asking for the square root of a list of numbers. If you have removed all the errors further up the file you can trigger the first error below by compiling the whole file (ENTER l1): */ ;;; The first line is fine, and should print out '** 2' Why? length([88 99]) => ;;; The next line produces a 'run time' error after the instruction is ;;; compiled, when the compiled code is being run. Why is this an error? sqrt([99 100]) => /* Fix the above command to make it print out the square root of 88 (or some other number). Then do ENTER l1 RETURN again, to make sure it works. Hint: the pop11 procedure sqrt operates on numbers, not on lists of numbers, whereas length can operate on lists and other things. Then delete both the above tests. Function Key F4 should delete the line the cursor is on. Or mark the line (ESC m) then delete the marked range using the command ENTER d */ /* Most of this file is inside Pop11 comment brackets. /* .... */ which look like the comment brackets in C and some other languages. (In Pop11, unlike most others, comments can be 'nested' as shown by the example three lines up, inside a much longer comment.) If you have fixed all the erroneous lines above that are not in comments, then the next time you do ENTER l1, you should have a pleasant surprise. */ 'Congratulations: Finished compiling TEACH MISHAPS' => /* If you renamed your file and want to save it, you can now do ENTER w1 ENTER q If you don't want to save it just do ENTER q If after that you are asked 'write it?' you can type 'n' for no, 'y' for yes 'c' for continue editing. -- Further reading ---------------------------------------------------- If you have used several previous programming languages you may find it useful to read the preface to the Pop11 primer: TEACH * PRIMER/'-- PREFACE TO' Use ENTER g to go to the preface TEACH * POPCORE Summarises the syntax of a useful subset of Pop11 TEACH * BUFFERS Moving around editor buffers TEACH * MINIVED TEACH * ESSENTIALKEYS Summaries of Ved/Xved commands and key combinations. TEACH * INDEX Shows many teach files available. --- $usepop/pop/teach/mishaps --- Copyright University of Birmingham 2011. All rights reserved. */