types and operators

[Nathan Hawkins]

On Sat, 27 Apr 1996, Captain Napalm wrote:

> A long long time ago on a network far far away, Eric W. Biederman thus said:
> > 
> >       B. pointers
> > 	 Pointers will need some basic operations, and some design decisions 
> >    will have to go into dealing with pointers into objects vs. pointer+offset. 
> >    We'll need operators to access all the supported types through pointers, 
> >    with indexing.
> > 
> > Operations for pointers seperate from those for integers, will
> > probably save us in the long run, as pointers sometimes take on the
> > stranges formats.  A lot of the pointer + index work can be relaxed
> > because a tidy house only needs to be presented at function call time.
> > In addition for large objects that pointer would ususally step through
> > recording where the object starts and have the garbage collector look
> > it up, shouldn't be a problem.
> > 
>   At the least, you need:
> 
> 	ptr + ptr --> ptr
> 	ptr + int --> ptr

We also will probably need a separate way to access characters/strings 
vs. integers. (Like CELL+ vs. CHAR+ in ANS Forth.)

> > I have figured out how to do type-safe operators (compile-time
> > type-safe) and identification of all pointers at run-time with no run
> > time cost.  What it does require though is a restriction on how words
> > can manipulate the data stack.   That is words must have a fixed
> > number of arguments and a fixed number of results. 
> > 
>   I'm not sure if I can live with that.  I like having a variable number of
> arguments, and a variable number of results (again, my Assembly days are
> showing through).
> 
>   There is a way around this though, by the use of pointers (to arguments
> and results), but that can be hidden.

That's one of my pet peeves with C and related languages. And yes, 
assembly hacking makes a drastic difference in what you like in a 
programming language...  And there's the classic mistake of the novice in 
C of returning a pointer to an automatic variable. A friend of mine tried 
to do that with a sizable struct. I got a very panicked phone-call at 3am...
(The assignment was due the next day.)

> > The reason I make the above restriction is as follows.  If words are
> > to use a single stack as C does they can be implemented as allocating
> > frames upon the stack.  The frame holding the funcions arguments, it's
> > return locate, the address of the last words frame, the local
> > variables, a buffer to receive results from functions, and most
> > important a tag that tells what everthing is in the frame.  
> > 
>   What's wrong with the following scenario:
> 
> 	Call a variable argument function (in a C like environment):
> 
> 		printformat("time: %t date: %D\n",time(),date());
> 
> 	And behind the scenes (still in a C like environment, but pretend
> 	it's at a lower level), you get:
> 
> 	pfa         = frame(3);	/* number of arguments */
> 	pfr	    = frame(2); /* number of results   */
> 	pfa.arg[1]  = "time: %t date: %D\n";
> 	pfa.arg[2]  = time();
> 	pfa.arg[3]  = date();
> 	__printtformat(pfa,pfr);
> 
>   Assignments will carry along any type information (okay, so the above is
> still a bit high level 8-)  Each function will have a fixed number of
> arguments (in the case of printformat(), internally, two) and a fixed number
> of results (in the case of printformat(), internally, none).

This would work, but it would be an annoying workaround, that I have to 
do to get things done in C, anyway. :-( (Ever write a function using 
varargs?) Besides, I still don't see why there must be type information 
on the stack that can't be kept with each element, since the type 
information would need to be stored in the heap when we put the elements 
there, anyway.
And please don't tell me we will have static structure layouts. That's 
another major flaw in C: you can't have dynamicly typed or sized 
components in a structure or array. Whereas by storing the type with each 
element, the LLL would be able to support far more dynamic and flexible 
data structures, for much the same reason that Lisp & co. can. At the 
same time, this should be very useful to the HLL.

*utsl*