Stephen Leach <steve@watchfield.com>
Wrote:
> Continuing the thread on the automatic insertion of Pop-11, I can
> report that I have a library of Ved functions that I wrote many
> years back (at least 10, I think) and continue to use on a daily
> basis.
Steve sent these to me in a separate message and they are now in
this directory
http://www.cs.bham.ac.uk/research/poplog/leach-utils/
in a small tar file
http://www.cs.bham.ac.uk/research/poplog/leach-utils/vedutils.tar.gz
whose contents are:
-rw-r--r-- sleach/users 91 1990-03-30 16:57:22 ved_add_define.p
-rw-r--r-- sleach/users 140 1999-07-28 21:32:56 ved_add_else.p
-rw-r--r-- sleach/users 165 1999-07-28 21:33:56 ved_add_elseif.p
-rw-r--r-- sleach/users 745 2003-08-27 10:14:34 ved_add_for.p
-rw-r--r-- sleach/users 149 1999-07-28 23:40:25 ved_add_full_if.p
-rw-r--r-- sleach/users 81 1999-07-28 21:23:30 ved_add_if.p
-rw-r--r-- sleach/users 162 2003-08-27 10:27:57 ved_add_indent.p
-rw-r--r-- sleach/users 93 1999-04-21 20:11:47 ved_add_lblock.p
-rw-r--r-- sleach/users 100 1990-03-31 19:00:11 ved_add_procedure.p
-rw-r--r-- sleach/users 94 1990-03-30 17:03:01 ved_add_repeat.p
-rw-r--r-- sleach/users 255 1999-07-28 21:29:49 ved_add_section.p
-rw-r--r-- sleach/users 88 1990-03-30 16:57:22 ved_add_until.p
-rw-r--r-- sleach/users 88 1990-03-30 16:57:22 ved_add_while.p
-rw-r--r-- sleach/users 706 2003-08-27 10:15:31 do_ved_add.p
> >Chris Glur (eas-lab@absamail.co.za) wrote
> > ...
> > >
> > > Remarkable ! Do the designers use it ?
[SL]
> Personally I thought that version was designed as a mnemonic
> reminder and NOT as a genuinely production tool. Here's what
> you get with "ENTER define RETURN"
>
> define NAME (PARAMETERS) -> OUTPUT;
> vars VARIABLES;
> enddefine;
>
> Clearly this is not properly formatted, includes deprecated
> syntax, and employs the less frequently used form of definition
> header with an explicit output.
Note how tastes differ:
I now tell all my students to use explicit output locals (and use them
myself)
a. because the reader then sees more immediately what the procedure
is about, compared with working out that certain results are
left on the stack by reading the code
b. in particular, the names of the output locals, if carefully chosen
help to make code more self-documenting and easier to debug and
maintain
c. we have a utility ENTER procheader which, when run with the
ved cursor on a line like
define grandmothers(person) -> (maternal_gran, paternal_gran);
Automatically generates the following just above the start of the
procedure definition, thereby encouraging students to document
their code as they write (preferably before they have got beyond
the first line of the procedure):
/*
PROCEDURE: grandmothers (person) -> (maternal_gran, paternal_gran)
INPUTS : person is a ???
OUTPUTS : maternal_gran, paternal_gran
Where :
maternal_gran is a ???
paternal_gran is a ???
USED IN : ???
CREATED : 29 Aug 2003
PURPOSE : ???
TESTS:
*/
See
http://www.cs.bham.ac.uk/research/poplog/help/ved_procheader
(or, if you have the Bham extensions, HELP ved_procheader )
I also try to teach students to distinguish the
*internal* semantics:
maternal_gran is a list containing two words
*external* semantics
where the list represents the first and last names of
the person's grandmother
(i.e. the former states what kind of pop11 data-type is the value of the
identifier, the latter states what it is intended to do in the context
of the application).
I found that made a large difference to the clarity of code and helps
students to think more clearly about what they are doing. Some of them,
having learnt to do it in year 1 going on doing it thereafter. Others
start lazy and end lazy.
[SL]
> On the other hand it is
> organized to maximize legibility and to remind the novice
> programmer of the tasks that could be done. So this is a
> memory aid, not a keyboard shortcut.
Correct, but if the format is followed it provides useful hooks
for other tools.
I never teach beginners to use pop11's dot notation (X.tl.hd) on the
grounds that there is an awful lot to learn and having to learn how to
decide between equivalent forms of syntax in different contexts adds to
the already great burdens. Also for procedures with more than one
argument the dot notation, though elegant (like postfix polish)
makes scope of expressions visually unclear. I often find that
inexperienced people who use it produce code that is hard for
the reader to parse.
But some discover the dot notation (e.g. if they read the primer) and
choose to use it in certain contexts, e.g. when accessing parts of
data-structures.
These teaching preferences lead to more typing and syntactically more
complex code. But I think that is outweighed by the benefits.
Aaron
|