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