From: Mika Heiskanen <mheiskan@cc.hut.fi>
Subject: Re: Anomaly in BLIND
To: joehorn@shell.liberty.com
Date: Fri, 4 Oct 1996 19:53:01 +0300 (EET DST)

[Note: This email refers to a previous version of BLIND which crashed
when run by typing its name rather than by pressing its menu key. The
version of BLIND on this Goodies Disk does *not* have this bug.  The
only reason I'm including this email here is for programmers to learn
how to avoid this bug in their own programs. -jkh-]

Joe,

This bug is due to the annoying use of LAM's when the editline is terminated.
When this happens the keyhandler saves the last KeyOb to 1LAM and evaluates
the editline as is - then recalls the 1LAM to evaluate the actual key
which terminated the editline. In the simple case of enter key the 1LAM
would actually only contain NOP.

What makes it annoying is that one cannot easily obtain information on how
a program was started. For SOL's the difference is that they also have to
handle stack saves, and this of course happens by creating a new lambda
environment. The keyhandler itself of course still expects 1LAM to contain
the KeyOb which terminated the editline, thus when the SOL exits it must

	o Either leave the saved stack as it is for the SOL below
	o Abandonn it so that 1LAM becomes visible

In this particular SOL I have now finally made an exit which should always
work - even UNDO immediately after the exit. This probably is not the case
with all SOL's - including those by me..

For your benefit I have included the source code of BLIND since the program
is not disassemblable due to assembly language jumps. However I do use a
personalized entry table which probably would make assembling the source
a bit hard for other people.

The crucial part is after the BEGIN-UNTIL loop

  UNDO_TOP? IT ABND		( Abandon saved stack from this SOL )
  TEN GETLAMPAIR		( Recall first lambda variable )
  casedrop CacheStack		( Handle the possibility of no 1st lam )
  UNROT2DROP			( Leave lambda name on stack only )
  EQ: PTR 5A777 ?SEMI		( Abort if it is the KeyOb save )
  CacheStack			( Else save stack again if necessary )
;

Note that an exit like this is only necessary when stack saves complicate
things - it is not necessary in regular programs.

I should note though that if the SOL is started by typing the name then
a subsequent UNDO after exit will restore the stack which one had right
before the SOL whereas UNDO after exiting a directly executed SOL will
do nothing since the stack is saved at exit. Changing the behaviour to
be uniform does not seem worth the extra code.

--
---
    --> Mika Heiskanen   mheiskan@gamma.hut.fi   http://www.hut.fi/~mheiskan