Path: utzoo!utgpu!attcan!uunet!seismo!esosun!ucsdhub!ucsd!sdcc6!ir230
From: ir230@sdcc6.ucsd.EDU (john wavrik)
Newsgroups: comp.lang.forth
Subject: Re: Hardware type checking
Summary: DOES> for typing
Message-ID: <3927@sdcc6.ucsd.EDU>
Date: 22 Sep 88 05:04:45 GMT
References: <829@cernvax.UUCP> <3066@pt.cs.cmu.edu>
Distribution: comp.lang.forth
Organization: University of California, San Diego
Lines: 36


Phil Koopman notes:
> A year or two ago, Hans Niewenhuser (I *know* I spelled it incorrectly!!)
> gave an argument at the Rochester Forth Conference that Forth has the
> potential to be a strongly typed language.  The argument for this is based
> on the use of CREATE ... DOES> ...  (or whatever your dialect calls it).
 
> In most implementations, the DOES> re-points the code field to the DOES> ...
> clause code.  So, if you make each kind of variable with its own DOES>
> field, then each kind of variable has a different CFA value.  The CFA
> value then contains the type information.  A clever compiler (especially
> an infix expression processor extension) can exploit this typing information
> to do automatic type conversions.
 
  This observation is correct, it can be used and it works well. Obviously,
however, the type checking only applies to named structures created by
the defining word mechanism -- and it works to best advantage if the
child words leave their address (cfa or pfa) on the stack. In this way
the typing can be used in normal Forth (without a processor extension).
This approach cannot be used, of course, to overload operation symbols
(like +) which can be as well applied to integers as to named data.
  There are versions of Forth which do not operate in this way (for example
the code field of a child word may point to a special "DOES" handler --
although in this case the pfa contains the address which can be used for
typing.
  Unfortunately, the idea depends on an implementation feature of Forth.
The Standards do not require DOES> to affect the cfa as indicated. From
all indications future standards will be even less specific about how
Forth should be implemented. Part of the power of Forth in the past
has come from our ability to exploit common implementation features like
this -- this may not be true in the future.
                                             --John J Wavrik
                                               Dept of Math  C-012
    jjwavrik@ucsd.edu                          Univ of Calif - San Diego
                                               La Jolla, CA  92093