Table Of ContentA gentle Introduction to ML
Andrew Cumming
Computer Studies, Napier University, Edinburgh
www.dcs.napier.ac.uk/course-notes/sml/manual.html
©Andrew Cumming 1995
Contents
Introductions
Functional languages are introduced.
l
Advice on how to use this document is given and CAL is dismissed.
l
Contributions from readers are presented.
l
Lesson One
"Hello World" is our first program.
l
Tutorial One concerns expressions and simple functions.
l
Diversion: The Reconcilation Ball
l
Lesson Two
Types, bindings, pattern matching and lists are all introduced
l
Tutorial two
l
Diversion: Bitmaps
l
Lesson Three
More on types, Currying and recursion
l
Tutorial Three (simple recursion on integers)
l
Diversion: The Mandelbrot Set
l
Lesson Four
List processing.
l
Tutorial Four (list and more lists)
l
Lesson Five
Incompleteness, Overlapping Left Hand Sides, Conditions, Anonymous
l
Functions.
Tutorial Five (even more recursion)
l
Diversion: Language Translation.
l
Lesson Six
Common recursive patterns, map, reduce, zip
l
Tutorial Six (higher order programming)
l
Diversion: Bus routes
l
Diversion: Election Special
l
Lesson Seven
Creating data types
l
Tutorial Seven (Queues)
l
Lesson Eight
Various tricks of the trade: accumulating parameters, mutual recursion, nested
l
definitions.
Tutorial Eight (accumulate)
l
Introduction to
Functional Programming
The functional language community
The functional language community is excessively dour. The functional ascetics forbid
themselves facilities which less pious programmers regard as standard . When using
functional languages we do away with notions such as variables and reassignments. This
allows us to define programs which may be subjected to analysis much more easily.
When a value is assigned it does not change during the execution of the program. This
property is referential transparency. There is no state corresponding to the global
variables of a traditional language or the instances of objects in an object oriented
language. When a definition is made it sticks. Reassignment does not take place. Getting
used to this and finding alternatives the traditional structures such as loops which require
reassignment is one of the hardest tasks for a programmer "converting" from a traditional
language. The line
x := x+1;
may appear in a 3rd generation language and is understood to indicate that 'box' or
'location' referred to as 'x' has its contents incremented at this stage. We do not admit
such concepts. 'x' is 'x' and 'x+1' is one more than x; the one may not be changed into the
other. A program without a state is a simpler thing - it is easier to write the code and
easier to reason about the code once written. It is harder to write poor code.
Functional languages are considered, by their devotees, to be higher level than third
generation languages. Functional languages are regarded as declarative rather than
imperative. Ordinary third generation languages such as Pascal, C (including flavours
such as C++) and assembly instruct the computer on how to solve a problem. A
declarative language is one which the programmer declares what the problem is; the
execution of the program is a low level concern. This is an attitude shared with the logic
language community (Prolog people).
Towards Correct Programs
There has been a great deal of progress in recent years in defining methodologies and
design techniques which allow programs to be constructed more reliably. Some would
claim that object orientation for example builds on and improves on structured
programming which undoubtedly contributes to a better process of software construction.
Using a rational methodology software engineers can produce better code faster - this is
to be applauded, however it does not bring us any closer to the goal of correct programs.
A correct program is not just more reliable - it is reliable. It does not just rarely go wrong
- it cannot go wrong. The correct program should be the philosophers stone for the
programmer, the pole star of our efforts. Software engineering may allow the intellectual
effort of the programmer to be used "more efficiently" however it does not necessarily
give us accurate programs.
Away from testing
Testing is usually regarded as an important stage of the software development cycle.
Testing will never be a substitute for reasoning. Testing may not be used as evidence of
correctness for any but the most trivial of programs. Software engineers some times refer
to "exhaustive" testing when in fact they mean "exhausting" testing. Tests are almost
never exhaustive. Having lots of tests which give the right results may be reassuring but
it can never be convincing. Rather than relying on testing we should be relying in
reasoning. We should be relying on arguments which can convince the reader using
logic.
The benefits and costs of correct programs
If correct programs were cheap and easy then we would all use them. In fact the
intellectual effort involved in proving the correctness of even the simplest of programs is
immense. However the potential benefits of a cast iron guarantee on a program would be
attractive in many situations. Certainly in the field of "safety-critical" systems formal
methods may have a role to play. It must however be admitted that the safety of many
such systems cannot be ensured by software - no amount of mathematics is going to
make a weapons system or a complex chemical plant safe. Formal methods may have a
useful part to play in systems where there is a high cost of failure - examples such as
power stations, air traffic control and military systems come to mind. The cost of failure
in any of these cases may be in terms of human life. The really important market for such
systems is in fact in financial systems where the cost of failure is money itself.
Why functional programming
Functional languages such as ML, Hope and Lisp allow us to develop programs which
will submit logical analysis relatively easily. Using a functional language we can make
assertions about programs and prove these assertions to be correct. It is possible to do the
same for traditional, imperative programs - just much harder. It is also possible to write
programs in ML which defy logic - just much harder. A functional language like ML
offers all of the features that we have come to expect from a modern programming
language. Objects may be packaged with details hidden. Input and output tend to be
rather more primitive then we might expect, however there are packages which allow ML
to interface with front ends such as X-windows.
Functional languages are particularly well suited to parallel processing - several research
projects have demonstrated superior performance on parallel machines.
Summary
We compare Formal Methods and Functional Programming with some traditional
Imperative Programming and traditional software engineering:
Imperative Programming & Functional Programming & Formal
Traditional Software Methods
Engineering
The Using informal language a Using logic we can state the
Development specification may be open to specification exactly. Using
Cycle interpretation. Using mathematics we may be able to prove
appropriate testing strategies useful properties of our programs.
we can improve confidence -
but not in any measurable way. Mistakes/bugs are common and
difficult to spot and correct.
Mistakes/bugs are common and
difficult to spot and correct.
The Using structured programming Using structured programming or
Development or object oriented techniques object oriented techniques we can reuse
Language we can reuse code. Using code. We can partition the problem into
structured programming or easy to use chunks - plus there are often
object orientation we can "higher-level" abstractions which can
partition the problem into more be made ML which would be difficult
manageable chunks. or impossible in a traditional language.
The Run-time The compiler can produce fast Code is usually interpreted, the
System compact code taking a fixed memory requirements are large and
amount of memory. unpredicatable.
Parallel processing is not Parallel processing is possible.
possible (in general). Fancy GUI's may be added, with
Fancy GUI's may be added. difficulty.
Introduction to using GIML
This document is in html - hyper text mark up language. html allows links to other
resources on the internet however almost all of the links here are internal - that is they
refer to other parts of the text. This document is basically linear however there are a few
side branches (like this) which will take you to another part of the document. To return
from such a branch use the back button on your browser.
How to use this document
It should be possible to copy text from the browser into another window. I usually work
with three windows. The browser (such as Netscape) is the largest, another window has
ML running and another has an editor. I typically will copy text from the browser into the
editor where I will change it, then from the editor into the ML window to test it.
On my machine I can select text with the left mouse button and paste it with the middle
mouse button - find out how to do it on yours.
Do you need to do the Diversions?
The diversions are important - real learning takes place when the student is engaged in
problem solving, using ML as a tool. The diversions are beginnings of projects, if you are
asking the question "how can I do this" you will remember the answer much more
successfully than if you are presented with a list of techniques. Check out Mindstorms:
children computers and powerful ideas by Semour Papert.
There is clearly no point in students slogging through diversions which hold no appeal
for the individual.
Is this computer aided learning?
The intention is to produce a mildly interactive document, it should be compared to a text
book rather than a CAL package.
CAL Rant
The user should have control at all times, you are not forced to go through the material in
any particular order and you are expected to skip the dull bits and miss those exercises
which are too easy for you. You decide. The author does not believe that CAL is a good
way to learn. CAL is a cheap way to learn, the best way to learn is from an interactive,
multi functional, intelligent, user friendly human being. The author does not understand
how it is that we can no longer afford such luxuries as human teachers in a world that is
teeming with under-employed talent. His main objection to CAL is that it brings us closer
to "production line" learning. The production line is an invented concept, it was invented
by capital in order to better exploit labour. The production line attempts to reduce each
task in the manufacturing process to something so easy and mindless that anybody can do
it, preferably anything. That way the value of the labour is reduced, the worker need not
be trained and the capitalist can treat the worker as a replaceable component in a larger
machine. It also ensures that the workers job is dull and joyless, the worker cannot be
good at his or her job because the job has been designed to be so boring that it is not
possible to do it badly or well, it can merely be done quickly or slowly. Production line
thinking has given us much, but nothing worth the cost. We have cheap washing
machines which are programmed to self destruct after five years; cars, clothes, shoes - all
of our mass produced items have built in limited life spans - this is not an incidental
property of the production line, it is an inevitable consequence.
The introduction of CAL is the attempt by capital to control the educators. By allowing
robots to teach we devalue the teacher and make him or her into a replaceable component
of the education machine. I do not see how such a dehumanizing experience can be
regarded as "efficient", the real lesson learned by students is that students are not worth
speaking to, that it is a waste of resources to have a person with them. The student learns
that the way to succeed is to sit quietly in front of a VDU and get on with it. The
interaction is a complete sham - you may go down different paths, but only those paths
that I have already thought of, you can only ask those questions which I have decided to
answer. You may not challenge me while "interacting". I want students to contradict, to
question, to object, to challenge, to revolt, to tear down the old and replace with the new.
Do not sit quietly and work though this material like a battery student. Work with other
people, talk to them, help each other out.
Readers Comments
Some real readers
Please send comments, questions or reviews to [email protected]
Readers remarks in bold
Andrew responds in plain
James Sears [email protected],
l
David Boyle [email protected],
l
Craig Salter [email protected]
l
Manjunathaiah Muniyappa [email protected]
l
Paul Pescod [email protected]
l
Dan Yoder [email protected]
l
Some made-up questions.
If ML is so brilliant how come no-one uses it?
ML is widely used in the academic community, it has not been taken up by people in
industry to any great extent. This may be because there are not enough people in industry
who understand the language. The acceptance or rejection of a system or standard by
industry is an extremely arbitrary process. There is no body or committee which decides
which are good systems and which are bad, popular systems arise for all sorts of reasons.
There have been cases when large corporations or cartels have effectively imposed
standards on the rest of us. Sometimes these standards are good and contribute to secure
stable environments in which good software practice may flourish - usually they don't
because the commercial interests of the large corporations or cartels depend on us
working with unstable systems that require upgrading every year or two.
To summarise:
There is very little logic in the way that the fashions and the moods of industry
l
develops. Industry flirts with structured programming or object orientation then is
prepared to give up software engineering altogether because of the look and feel of
Visual Basic.
The few people who may be capable of directing these fashions would run a mile
l
from a free programming language which doesn't need changing.
ML is not a proper language 'cos it doesn't run on a PC.
It does actually. The point remains that it is a relatively expensive language to run - but
then some versions of C++ are not any better. See the FAQ (comp.lang.ml.faq) for how
to get hold of implementations.
ML is not a proper language 'cos it can't be used to build applications with 3D
buttons and context sensitive help.
This is a serious issue. There is a system called eXene which allow ML to control X-
Windows.
It should be conceded that tarting up a program is easier in Visual Basic than it is in ML,
it maybe even easier in C or C++ than ML. As ML can read and write files it may be
slotted into any other system, the fact that it has little in the way of HCI embedded
protects it from fickle fashions. The windows and pull down menus applications that are
being built today will quickly look as old fashioned as the character based forms of last
year. With its text only interface ML has the advantage of looking old fashioned already.
The chances are that if you write a program in ML today you will still be able to run it in
ten years time. If you write it in C++ and use the Windows interface your chances of
celebrating the program's tenth birthday are slim.
But it hasn't got a or a or even a .
Real programmers don't use buttons. If you seriously think you need to single step your
programs there are tools available (using emacs for example), however the author
believes that these are more trouble than they are worth.
Still not convinced.
Have you considered following another course? An MSc. in Object Oriented Software
Engineering is offered by the Department of Computer Studies at Napier University;
suitable for computing graduates, it is 100% ML free.
