types and operators

[Nathan Hawkins]

On Sat, 27 Apr 1996, Captain Napalm wrote:
> A long long time ago on a network far far away, Nathan Hawkins thus said:
> > On Thu, 25 Apr 1996, Eric W. Biederman wrote:
> > >       C. strings
> > > 	 I favour using counted strings, and providing a good set of 
> > >    operators to work on them. We will need to mark strings so that the 
> > >    garbage collector knows to leave them alone.
> > > 
> > > I'm not sure why the gabage collector needs to leave these allone.
> > > Except that it needn't look for pointers in them.  But certainly if
> > > it can be proved that the string can't be used the GC should reclaim it?
> > 
> > I'm sorry, what I meant was that the GC shouldn't bother search strings 
> > for pointers. Therefore, strings must be marked so the GC knows what they 
> > are. QED.
> > 
>   If you have to mark some types (even one) you might as well go all the way
> and type everything.  It makes the implementation a bit easier as well as
> more orthogonal (which I like - the VAX Assembly language perhaps being the
> MOST orthogonal instruction set ever 8-)

Well up to a point, yes. Depends on how you mean, but I'll tentatively 
agree with you.
As for VAX assembly, I've never used it, but from what I've heard, it 
would be interesting. I liked the 6809 for much the same reason, while I 
hated the Z80 and the x86 because they were so asymmetrical.

[stack frames]
> > This restriction is would get obnoxious in almost no time. We're talking 
> > about writing a very extensible language which can be expanded to handle 
> > doing a lot of things dynamically. In your design, I couldn't even write 
> > a function like printf! Not to mention breaking the separation between 
> > the data and return stack. I'd rather stay closer to Forth.
> > 
>   See my previous message.  And don't be afraid of moving further from the
> "Forth" ideal.  Use what's good, throw away what can't be used.
> 
> > Well, in Forth, we don't use local variables, anyway. 
> 
>   <Tonto> What's this "we" business, Kimosabe? </Tonto>
> 
>   ANS Forth does have local variables.  They're not used much, but they are
> there.  And for certain operations, they are nice to have (okay, draw a box
> in Forth, given the primitive LINE ( x1 y1 x2 y2 -- )).

Sorry, I was wrong there, I should have said I don't use them, and I keep 
forgetting about certain ANS extentions, 'cause I'm still more familiar 
with '83.

> > I think I'd rather put up with type munging. :( :( :(  You see, I'd like 
> > to remain as close to Forth in design as is possible, but with the 
> > needed extentions. (As well as dumping some minor stupidity in the Forth 
> > I/O words.) But I do want it be close enough that most ANS Forth would 
> > run, provided it obeys the rules of ANS Forth.
> > 
>   I wouldn't be that concerned with ANS compatability.  You can always add
> an ANS layer (provided your base has a good foundation).

Sure, but I'd like it to be close enough that this is easy. We're talking 
about major design issues for the language, not relatively minor 
implementation things. And I would consider stack frames on a single 
stack or the heap to be a major departure from the Forth model, probably 
a total incompatibility. Which would be sad, as well as losing a major 
strength of Forth. (The highly flexible parameter/return-value passing.)

> > In general, I'd like to stay away from stack frames. I'd prefer to not 
> > have those at all, or let the hll use them if it wants. But not in the 
> > lll, or its calling convention. Those are just my preferences, though. 
> > We'll have to see what other people think.
> > 


>   From _Computer Programming and Architecture: The VAX-11_ by Henry Levy and
> Richard Eckhouse, Jr.:
> 
> 	Argument Lists and Call Instructions
> 
> 	  For the VAX-11, arguments are transmitted to a called procedure
> 	in an argument list.  A VAX-11 argument list is an array of
> 	longwords [each longword is 32 bits -spc]in which the first longword
> 	contains a count (in the first byte) of the number of arguments to
> 	follow....
[rest of the quote deleted]

This sounds exactly like a microcode implementation of the standard C and 
Pascal (although more like Pascal) stack frame. I don't like this, for 
the previously mentioned reason.

*utsl*