/*
TEACH MISHAPS A. Sloman Nov 2011
CONTENTS - (Use <ENTER> 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: <ENTER> l1 <RETURN>
(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:
<ENTER> name my_mishaps.p <RETURN>
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.
<ENTER> name MyMishaps.p <RETURN>
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):
<ENTER> 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
<ENTER> 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
<ENTER> 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')
<ESC> x
ENTER clear
<ESC> 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.
*/