types and operators

[Captain Napalm]

A long long time ago on a network far far away, Nathan Hawkins thus said:
> 
> 
> 
> On Tue, 23 Apr 1996, Eric W. Biederman wrote:
> > Now all we have to do is figure out is what kinds of data types and
> > which opeations on them, our lll will support.
> 
  [ FYI - major editing ]

> I. Data types we will _need_
>    A. integers
>    B. pointers

  It seems you want to be able to distinguish between integers and pointers
by looking at the (for lack of a better term) object rather than carry type
information around.  I feel that's not the way to go and would rather carry
around type information (external to the object, in the case of integral
(internal) types).  

  For instance, given the following:

	integer     color  = 0x00083414;
	integer ptr pcolor = &color;	// given the memory map, this is
					// at address 0x00092D08
 (in some pseudo-Cish language)

  By just looking at the objects, how can you determine what they are?
  
>    C. strings
> II. Optional types
>     A. buffers
>     B. floating-point
>        Floats would be a mess to do, especially when it comes to 
> distinguishing them from integers, pointers and strings. This can 
> probably be added later.
> 
  If you mean by looking at the object, yes, it will be difficult, as will
be distinguishing between integers and pointers (see above).

>     C. double-length integers
> 
  And how do you determine an integer from a double integer?

> There will need to be some thought put into stack operations. I was 
> planning on keeping the standard Forth ones. Any comments on this?
> 
  One thing I dislike about Forth (and this comes from years of Assembly
experience) is the amount of "stack noise" that comes about from
manipulating the stack.  I personally like the ability to address the
"stack" as an array, but at the same time, I know this violates the purity
of Forth (or of stack based languages in general) and may be difficult to do
depending upon the implimentation.

  For lack of any better advice, okay.

> Also, I'd like to have a some ideas about how to do pointer/integer 
> distinction with a minimal instruction count for operators. Since + - * / 
> etc. will all have to convert LLL integer --> machine integer 
> conversion and back, I'd like it to be kept to something we can do with a 
> minimal instruction count.
> 
  Separate type information.  This doesn't have to be kept around all the
time (like some Forth systems strip the headers of each word once the
application is written - not all words are meant to be used at the highest
level).  Once the "program" is running, then type information (and type
checking) can be removed.

> Finally, a question of operator behaviour: should operators be type-safe, 
> or should they just produce undefined results? For instance: what happens 
> when you add a pointer to an integer with the integer addition operator?
> Also, if operators are type-safe, what should they do when given the 
> wrong parameters? (Exception-handling?)
> 
  During development, they should be type-safe and if an illegal type is
specified, an exception should be thrown (or dumped into a debugger). 
Dumping core is NOT an option 8-)

  During regular use (assuming the program has been fully debugged) then
there should not be any type mismatches, but if something does happen, the
easiest (and fastest) would be for undefined behavior/results.  Buyer
beware and all that.

  -spc (view type-safe operations to be a form of debugging ... )