Don't forget to attend EuroForth 2008 and the Forth200x standards
meeting in gorgeous glorious Vienna from 25-28 September 2008.
http://www.euroforth.org

I have separated the enhanced local variable syntax from the
local buffer proposal. This proposal is about local buffers.

Stephen

RfD - Local buffers, v4
=======================
Stephen Pelc - 14 September 2007

20080811 Brought into line with LocalsExt4.txt.
20070914 Split local buffers to a separate proposal.

Problem
=======
When programming large applications, especially those interfacing
with a host operating system, there is a frequent need for temporary
buffers. This proposal is an extension to the extended locals
proposal, on which this proposal depends.

Stephen Pelc mpeforth.com> wrote:

This is all very interesting, but why not just have a word LBUFFER
that allocates some (return) stack space? You could use it like this:

4 chars LBUFFER to buf

I suppose this is similar to the variable-length array declaration in
C versus alloca():

int *p[N];

versus

const int *p = alloca(N * sizeof (int));

which are for almost all purposes equivalent.

I'm a bit mystified. There is an obvious simple syntax (LBUFFER,
above) and a complex special syntax. Given that Forth generally
eschews special syntactical forms, I can't see why you want this.

Andrew.

On Aug 11, 12:30 pm, Andrew Haley
wrote:

Or?

4 CHARS LBUFFER { buf }

... since the basic { } locals syntax without all the extra syntax
gives the ability to declare a local value without necessitating a
dictionary entry ...

... would that be right?

I must say of all the proposed extended locals syntax, the local
buffer is the only bit I really want, and this looks like a reasonable
way to get it.

According to Andrew Haley :

I see some implementation problems:

-- The LBUFFER word must be special, since it must allocate things on
the return stack _as seen by the caller_, notwithstanding what the
call procedure to LBUFFER itself pushed on that very same stack. This
may be quite tricky in some implementations.

-- Local variables are fast and easy to access as long as the return
stack remains untouched. Basically, locals are meant to be accessed by
using the return stack pointer, with a fixed offset computed...

Bruce McFarling netscape.net> wrote:

Yes.

Andrew.

Thomas Pornin bolet.org> wrote:

I don't believe it will be all that tricky. Certainly no more tricky
than local variables.

According to Andrew Haley :

If your compiler supports local variables, then the obvious way to
implement DO...LOOP is to reserve an unnamed local variable for
the loop counter. The number of loop constructs in a given word
is small and known at compile time. Using a local slot for the loop
counter implies that it is perfectly compatible with accessing
locals by offsetting the stack pointer.

Besides, the ANS provisions about return stack usage (i.e. that you
shall not access local variables if you played with the return stack)
strongly suggest that offestting from the stack pointer is meant to
be supported.

Thomas Pornin bolet.org> wrote:

Well, that's a way to do it: I strongly dispute that it's the obvious
way, especially on a small system, but let's move on.

Right, which is what the proposal is all about. The purpose of this
is a way to get variable-size local buffers.

On Mon, 11 Aug 2008 11:30:42 -0500, Andrew Haley
wrote:

It's been done, but in this proposal release is automatic at EXIT
and friends. In your proposal you need an undo operation. You
still need a local for buf, so we end up with
: foo { a b | c d buf }
4 chars LBUFFER to buf
...
buf DISCARD
;
versus
: foo { a b | c d [ 4 chars ] buf }
...
;

On Aug 12, 10:59 am, stephen...@mpeforth.com (Stephen Pelc) wrote:

I don't follow this ... why is automatic release harder for LBUFFER
than for { ... | ... [ ... ] ... }

This is in an independent proposal to the "|" proposal, so wouldn't it
be:

: foo
4 CHARS LBUFFER { buf a b }
...
;