[comp.lang.forth] ANS TC - BETWEEN THE CRAC

ForthNet@willett.UUCP (ForthNet articles from GEnie) (01/06/90)

 Date: 03-23-89 (09:37)
   To: DENNIS RUFFER
 From: GENE LEFAVE
 Subj: ANS TC - BETWEEN THE CRAC

 Dennis,
    This is the first time I've checked in here, and as a long time forth
 user and polyFORTH user at that, I thought I'd get my two cents in.
    I think both ASCII and [ASCII] should be banned.  I've always changed
 either NUMBER or INTERPRET to recognize the string "x" as a number.  I
 can't see any benefit at all in using an extra word before a character.
 It just doesn't seem to be consistent with the rest of the syntax.
   A alternative solution might be a general mechanism for attaching a
 user routine to NUMBER in dealing with unrecognized words.  There is
 really little time penalty associated with this.  By the time NUMBER
 gets control the dictionary has already been searched.  A couple of
 extra checks before aborting have little impact.
    I was quite surprised when ASCII turned up in polyFORTH.  It just
 doesn't feel like a word that FORTH Inc would ever use.  I think its
 use always obscures the reading of a program rather then enhances it.
 Your thought process always has to break and decide what ASCII means in
 the context of some operation.   "x"  is always obvious and doesn't
 assume a specific character representation either.  It's also one of the
 few prefix words I can think of that would turn up in typical
 application programs.
    Gene

ASCII is clutter.  Like your system, I've also encountered a need for more
than one character at a time.  So, 'AB' also works.  But, unlike   _ 01  
which is $3130,  '01'  is $3031.  I can understand the Intel order from an
implementation viewpoint, but doesn't this make comparisons more difficult in
applications?

I see no justification for a state dumb CHAR .  FST blew it when they changed
' and added ['] .  They had the choice of calling the state dumb tic  &  , and
leaving ' smart.  The rest of the state smartness argument is a
misunderstanding based on the need for a state dumb tic.

-----
This message came from GEnie via willett through a semi-automated program.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'