types and operators

[Captain Napalm]

>From some obscure corner of the Matrix, Nathan Hawkins was seen transmitting:
> 
> 
> On 14 Jun 1996, Eric W. Biederman wrote:
> 
> [lots of stuff deleted]
> 
> > > > > 2. Lisp-style cells, a pointer w/tag, and a 32-bit data element
> > > > >    Pros:
> > > > >      * hl things would be easy to implement
> > > > >      * doesn't lose any bits from pointers and ints :-)
> > > > >      * don't need to worry much about fragmenting the heap
> > > > >      * the stack could be implemented as a list on the heap
> > > > >    Cons:
> > > > >      * costs twice as much memory for each cell
> > > > >      * probably quite inefficient
> > > > > 
> > > > 
> > > > <commentary>
> > > > I think those extra 31 unused bits would get very tempting to use for
> > > > something.  I can imagine all kinds of hacks we could regret later.
> > > > Also I don't quite see how that would bye us much but one bit at the
> > > > expense of 31 for implemtation purposes.
> > > 
> > > I certainly didn't intend to waste them. :-) Specifically, I was thinking 
> > > in terms of lists, implemented almost identically to Lisp. Keeping the type
> > > tag in the cdr part of the cell would allow us to have 32 bit pointers 
> > > and integers on the car side.
> > 
> > That's the problem.  You will use those.  The code we write, or the
> > techniques we chose will not resemble those of Forth.  If our guide
> > for the LLL is to be Forth it should be essentially Forth.  Under
> > Option 1 we can write a GCing ANS Forth as fast as any other.  Under
> > this plan who knows what we will write but it won't be Forth.  Further
> > the compiled code will be implemented quite differently.
> > 
  There is Forth, and then there's Forth.  I've implemented a Forth-like
language that is precicely that, Forth-like.  It's not Forth.  And the next
revision of that language is even less like Forth (or more like Forth than
Forth is) yet the ability to have ANS Forth code is possible (I have a
problem with the way ANS Forth defined flow control words, but that's due to
prior art in Forth systems - I won't let that stand in the way of a nice
implementation 8-)

  I might want to ask:  What is Forth?  Is it the idea of a stack based RPN
language?  Or is it what ANS Forth is?  Or F-83 or Forth 83 or Forth 79 or
...

> > My point is we'll get lost in this implementation and never get
> > anywhere as Fare was in M4 and assembly.
> 
> You're probably right there... I still think it would a very interesting 
> idea, but I'll agree to go with option 1 for the initial implementation, 
> as you describe it. Sounds good to me.
> 
  I disagree.  Option 2 is much better in the long run (and TUNES is a
Useful, Not Expediant System, although at times it certainly seems as if
everyone is trying for an Expediant system).  

  Sure, you loose memory, but you gain a mich finer control of type
information (in fact, who's to say that the type information is a series of
bits, it could be the address of a function, say), and once you know the
code works with static types (i.e. code where the type information is
determinate and doesn't chance from run to run) then you can remove the type
checking code and the types themselves!  And you never loose precision in
your integers, characters, pointers or floats.

> > If we can tack a GC onto Forth,  will remaining ANS compliant (At least
> > after we load the ANS compatibilty wordsets) we will have acheived
> > something I think no other Language has done, and show how truly
> > reflexive forth really is.
> 
> We could do that. The question that remains is, what do we really want to 
> do? I lean a little more towards Forth-83 than ANS, for example. ;-) 

  Forth-83?  Yeeesh, I like the ANS Forth better than Forth-83.  Let's see,
Forth-83 standardized upon a 64k byte addressable space with cells being two
bytes and pointers being two bytes and to hell with everything else.

  But that's my opinion 8-)

> Some of 
> the HLL people might like the Lispish Forth better. (Big surprise that'd be.) 

  I'm not one of the HLL people and I like the Lispish Forth better (since
that's seems to be the way my Forth-like lanaguage is headed).

  -spc (And Postscript is more Forth than Forth is ... )