[M3devel] heap vs. stack? (sort of)

[hendrik at topoi.pooq.com]

On Mon, Jan 28, 2008 at 02:00:46PM +0000, Jay wrote:
> Both.
> In thinking about how to write the code, there is no point in splitting the code into two functions.
> They are each small and the one is only called once.
> The language should in general not force me to write functions merely to work over the type system.
> <*inline*> is not implemented by the integrated backend. I assume every function call I write will not be inlined.
>  
> > Functions can return pointers to open arrays - isn't this enough?
>  
> Yes that might help.
> I had tried like
>  
> PROCEDURE PickBuffer(VAR buf: ARRAY OF CHAR; len: INTEGER): ARRAY OF CHAR =
> BEGIN
>   IF len <= NUMBER(buf)    RETURN buf;
>   END;
>   RETURN NEW ARRAY OF CHAR (len);
> END PickBuffer;
>  
> PROCEDURE Parse(...)
> VAR
>    stack: ARRAY [0..255] OF CHAR;
>  BEGIN
>   ...
>   WITH buf = PickBuffer(stack, len) DO     use buf
>    END;
>  END Parse
>  
> but I couldn't come up with a PickBuffer that the compiler liked.
>  
> PickBuffer is still a bit iffy.
>  
> More generally in C++ I would implement that as a template class where one of the parameters is how much to preallocate. In C I would implement it as a struct and some functions and the initialization function would take the preallocated buffer and size.
>  
> Surely Modula-3 can do either/both of those patterns well and it doesn't have to be reimplemented over and over.
>  
> The Modula-3 code I see around the system is way more low level and repetitive than seems appropriate, more so than C code that I write.
>  
> Another example is that it definitely appears that if I try to compile code with a path like
> \a\b\c\d\e\f\g\h\a\b\c\d\e\f\g...\foo.m3
>  
> that has more than around 32 path separators, I'll just get some random failures since the code just "gives up".
> M3Path has an array of 32 to store the positions of path separators.
> That whole chunk of code, to remove \.\ I'll probably rewrite to be both more efficient and have no such capacity limits.
> For \.\ it is trivial.
> For \..\ it takes a bit of cleverness -- rather than rely on any indefinite amount of storage, what you can do is first reverse the string, then whenever you se .., bump up a counter, whenever you see not .., bump it down, only copy from source to dest when the counter is zero. Roughly.

If you are talking about paths for naming files, you might want to 
consider that (on Unix systems at least) '..' does not back out of a 
symbolic link, but may go somewhere else entirely.  Whether you want 
this behaviour is, of course, up to you.

-- hendrik