🚀 go-pugleaf

gateley@m2.csc.ti.com (John Gateley) writes:

>In article <12507@mcdphx.phx.mcd.mot.com> kjj@varese.UUCP (Kevin Johnson) writes:
>>1. How about string operators.
>>	I hate handling allocing of space for something silly like strings...

>But, string sizes are not known at compile time, and so must be handled
>by the heap (i.e. alloc).

Right. Now if you're gonna put dynamic allocation in your language
anyway, don't forget to handle "automatic" growing of the stacks
in multithreaded environments.

This cannot be done by the operating system, since the virtual
memory just above the top of the stack that needs to be grown may
be used by another thread's stack.

The compiler can do this by checking at each procedure invocation
that the stack is at least big enough for this frame, and if not,
allocate a stackframe at the heap.  If this allocation fails, you
got a stack overflow. (I did something similar in a multithreading
package for the AtariST).


You can also take this message as a funny way to try to convince
you that you're probably not going to succeed in designing a language
that will please everybody. I guess the original poster is probably
already convinced by messages suggesting to implement Lisp, C++,
ML, and what-have-you-there :-)

	Siebren, siebren@cwi.nl