Path: utzoo!attcan!uunet!willett!ForthNet
From: ForthNet@willett.UUCP (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: Vocabularies
Message-ID: <662.UUL1.3#5129@willett.UUCP>
Date: 16 Mar 90 04:00:10 GMT
Organization: Latest link in the ForthNet chain.  (Pgh, PA)
Lines: 40

Category 3,  Topic 18
Message 6         Thu Mar 15, 1990
D.RUFFER [Dennis]            at 01:53 EST
 
 RE: CHRIS WATERS

 >    If you could, I'd like some more details about why you have
 > problems with these constants.

I wasn't at Forth, Inc. (or at least not locally) when the problem came up,
but from what I know, it has to do with resetting the flags that tells LITERAL
what type of number was just interpreted.  In our case, we allow LITERAL to be
vectored as well as NUMBER.  Thus when you add a new number type, such as
floating point, LITERAL can still be used to compile them into a definition. 
Since NUMBER is the only thing that knows what the number was, it sets the
flag.  It becomes essential that all numbers go through the process since new
flags may be added with new number converters.  You may even need to use the
flags further down the line, so LITERAL can not just reset them. Also, since
LITERAL is used in the compiler (]) it sometimes needs to be revectored on the
fly to know how to compile a number that appears right in a definition.

I just looked at how pF handles floating point numbers.  NUMBER is revectored
to scan for a decimal point followed by a non-blank character.  When a number
such as this is encountered, LITERAL is revectored to another vector which can
handle either 32 or 64 bit real numbers.  Otherwise, the system number
conversion is used which vectors LITERAL back to its default behaviour, which
may have been revectored by the user.

Adding the support to handle this complexity would be too involved for
CONSTANT.  We don't want the user to have to change too many vectors just to
add a number type.  NUMBER and LITERAL are essential, and sufficient to solve
the problem.  Besides, any overhead that they incure would only be at compile
time or when interpreting user input where execution time is not critical.
Adding support for this to CONSTANT would incure run time overhead, which in
the case of real-time applications, can be very critical.

DaR
-----
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'