Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!willett!ForthNet
From: ForthNet@willett.UUCP (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: Vocabularies
Message-ID: <699.UUL1.3#5129@willett.UUCP>
Date: 22 Mar 90 23:46:18 GMT
Organization: Latest link in the ForthNet chain.  (Pgh, PA)
Lines: 46


 Date: 03-18-90 (00:04)              Number: 3055 (Echo)
   To: DENNIS RUFFER                 Refer#: 3030
 From: CHRIS WATERS                    Read: NO
 Subj: VOCABULARIES                  Status: PUBLIC MESSAGE

 DR(what type of number was just interpreted.  In our case, we allow LITE
 DR(vectored as well as NUMBER.  Thus when you add a new number type, suc
 DR(floating point, LITERAL can still be used to compile them into a defi

 DR(Adding support for this to CONSTANT would incure run time overhead, w
 DR(the case of real-time applications, can be very critical.

    Well, my original question had to do with why constants such as 0
 and 1 would cause problems with re-vectored number interpreters.  The
 "it's-there-but-you-can't-use-it" technique of hiding these these
 constants by removing their headers seems extremely un-forth-like to
 me.  It should be the system's job to provide tools, and the
 application's responsibility to protect the user from those tools.  :)

    Extending the syntax understood by NUMBER is very useful, but
 changing the default syntax strikes me as extremely dangerous. If I
 enter '20' and the interpreter does not return the single precision
 value 20 to the stack, I'm going to be in serious trouble the first
 time I enter 'PAD 20 ERASE.'  If FORTH is not in the search path, this
 is not a problem, but constants such as 0 should be in the Forth
 vocabulary anyway.

    I do not think that the small class of applications that conflict
 with these limitations should penalize all other applications.  No one
 has said that they have removed these constants to avoid data-type
 conflicts.  Removing their heads seems to be the preferred method.
 This would indicate to me that these constants are useful.  Useful
 enough to make available.  I often use conditional interpreting to
 include some of these constants in my applications if they are not
 already defined.

 Chris

 -> MegaMail(tm) #0:he used to cut the grass, he was a very nice boy
    1.12

 NET/Mail : The Snake Pit - 408-287-2353 - San Jose, CA - Home of ProBBS
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'