[To reply replace "Aaron.Sloman.XX" with "A.Sloman"]
cglur@onwe.co.za writes:
> article: 2644 in comp.lang.pop
> Date: 3 Mar 2001 08:05:45 GMT
>
> Three queries re. teach river2:
>
> 1.
> Typo at line 288:
> You can you check that this modified procedure....
I think you are still using the "old" teach river2 that is part of
the standard poplog distribution, and has many serious flaws. Many
of the teach files, including this one have been improved in the
Birmingham package bhamteach.tar.gz.
The new version of TEACH River2 is also accessible on its own at
http://www.cs.bham.ac.uk/research/poplog/teach/river2
> 2.
> "Take the fox right across, then back again, for example.
> start();
> putin([fox]);
> cross(); <---- line 393 ? cross(); NOT crossriver();
> takeout([fox]);
> database ==> "
>
> It seems to me that cross(); is not defined ? A typo ?
I think you'll find that earlier on defining it was set as as
an exercise. The same thing had already been done in TEACH RIVER.
define cross();
getin();
crossriver();
getout();
enddefine;
Look at line 212 of the old teach river2.
> " The procedures which change the world are:
> PUTIN TAKEOUT GETIN GETOUT CROSSRIVER "
Cross can be defined in terms of those.
> My understandng of boats does not correspond to the depicted world.
> Specifically that the boat can cross, without the man ? !
>
> " -- PRECONDITIONS --
> 1. PUTIN (object)
> 1.c The boat must be at the same location as the object
> 1.d The man must be at the same location as the object "
> 1.c AND 1.d have redundancy, unless it is assumed that the boat can
> 'move away from' the man.
> It seems to me that crossriver(); should have the precondition:
> The man must be in the boat;
> then 1.d becomes redundant.
I can't remember details of that file, but in general there are often
tradeoffs between more and less redundant ways of representing
information.
> 3.
> My syntax error:
> getout([man]);
That's not a syntax error: it is perfectly legal Pop-11. It's a semantic
error.
Because pop-11 procedures can take arbitrary numbers of arguments and
the number does not need to match the number of formal parameters in the
procedure definition, and because some of the arguments may have been
left on the stack before the procedure call (as in Forth), it is not
possible for the compiler to tell from the form of an expression
invoking a procedure whether there is an error or not.
Example a procedure to add up n numbers.
define addup(n) -> total;
0 -> total;
repeat n times
;;; add top of stack to total
+ total -> total
endrepeat;
enddefine;
addup(1, 2, 3, 3) =>
** 6
addup( 2, 4, 6, 8, 4) =>
** 20
addup(0) =>
** 0
> A guess that the spurious parameter(s) are just left on the stack after
> the procedure exits, was not confirmable ?
yes, e.g.
addup(2, 4, 6, 2) =>
** 2 10
====
Aaron Sloman, ( http://www.cs.bham.ac.uk/~axs/ )
School of Computer Science, The University of Birmingham, B15 2TT, UK
EMAIL A.Sloman AT cs.bham.ac.uk (ReadATas@please !)
PAPERS: http://www.cs.bham.ac.uk/research/cogaff/
FREE TOOLS: http://www.cs.bham.ac.uk/research/poplog/freepoplog.html
|