Path: utzoo!attcan!uunet!willett!ForthNet
From: ForthNet@willett.UUCP (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: PYGMY Forth
Message-ID: <1234.UUL1.3#5129@willett.UUCP>
Date: 29 Jun 90 03:56:21 GMT
Organization: Latest link in the ForthNet chain.  (Pgh, PA)
Lines: 68

Category 1,  Topic 45
Message 29        Thu Jun 28, 1990
F.SERGEANT [Frank]           at 02:01 CDT
 
     Len, thanks for the comments.  I'm sorry I misunderstood about the  disk
being one giant file, but glad to find out you like how Pygmy  handles files. 
(It was more amusing, though, when I thought you  objected to it being one
giant file at the same time Robert objected to  it NOT being one giant file.)

     About NUMBER, I have a few random thoughts but no definite  suggestion:

     I, also, like that it *uses* the count rather than requiring a  space at
the end of the string.  It's always seemed silly to me to use  a counted
string and ignore the count and require that it actually be a  delimited
string.  

     The only thing that makes the string a bad number is one of the 
characters not being a valid digit, so I see a certain harmony in  -DIGIT
blowing up if it gets a bad digit.  I think this is just a  mental trick.  If
I *prefer* it the way it already *is* then I don't  have to do any work to
change it!  With that disclaimer, I'll continue.

     -DIGIT blowing up is entirely satisfactory when the user uses a 
collection of Forth words as tools.  That is, he types a number and  then a
command.  It only becomes a problem when the application prompts  the user for
a number.  It is a question of who is driving whom.  Since  we are going to
the trouble of giving the user a 'turnkey' system, it  seems sloppy to allow
him to make a mistake that crashes the system.  

     I am not arguing against this.  I think there are many times when  we
*must* insulate the user & the application from each other.  I have  some
regret over it, though.  One of my favorite thoughts (not  original) is that
sometimes you need things but sometimes you only need  things because your
things need things.  So, *we* don't need any  fancier error
recovery/prevention, unless we've already added the  complexity of a fancy
user interface.  Like I said, I'm not trying to  talk us out of fancy user
interfaces.  I think we have to have them to  stay competitive (but I'm not
quite happy).

     The Michael Ham & Mike Elola & Glenn Linderman articles in FD, etc  have
been attempts to deal with this very problem.  One approach was to  detect the
error, as you've suggested, without blowing up.  Another is  to refuse to
accept an invalid keystroke.  It doesn't seem that either  of these properly
belongs in NUMBER.

     If I were to make a suggestion (you've heard of Boolean Logic, and  Ill
Logic, and CMOS Logic, and Mickey Mouse Logic, well this is based  on Inertial
Logic as I discussed earlier) it would be to leave NUMBER &  -DIGIT alone. 
They do what they do just fine.  Instead add a new word  to do just the
testing, just when it is needed.  NUMBER? might be an  acceptable name - or
VALID? or VALID-DIGITS?.  Now, I'm guessing that  this would find use
exclusively for users using decimal base.  It might  not be worth making it
general by consulting BASE, but it could be.  It  would take a string and
check it for valid digits and return a flag.   Here's a quick version that
omits checking for minus signs, etc.

 : VALID? ( a - f) 
   COUNT FOR ( a)   C@+ '0 '9 WITHIN WHILE     NEXT DROP -1 ( f) EXIT
   THEN ( a) DROP (   ) POP ( index) DROP 0 ( f)  ;

     There is more to user input validation than this.  Sometimes  negative
numbers are ok, sometimes only a certain range is ok, etc.

     Thanks for the suggestion.  I'll add it to the stack as I re-work  Pygmy
for version 1.3.
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu