Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

The last thing one knows in constructing a work is what to put first. -- Blaise Pascal


devel / comp.lang.forth / locals and metaprogramming

SubjectAuthor
* locals and metaprogrammingAnton Ertl
`* Re: locals and metaprogrammingRuvim
 +* Re: locals and metaprogrammingminf...@arcor.de
 |`* Re: locals and metaprogrammingRuvim
 | `- Re: locals and metaprogrammingminf...@arcor.de
 `- Re: locals and metaprogrammingRuvim

1
locals and metaprogramming

<2022Jan23.183317@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=16383&group=comp.lang.forth#16383

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.lang.forth
Subject: locals and metaprogramming
Date: Sun, 23 Jan 2022 17:33:17 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 53
Message-ID: <2022Jan23.183317@mips.complang.tuwien.ac.at>
Injection-Info: reader02.eternal-september.org; posting-host="231a70890999f0984e9e4b5f17818584";
logging-data="13502"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18R32HFDwLRwOLX61H/XvrY"
Cancel-Lock: sha1:cEl0OAMuD4S3DzaWOlV5t3JwUr4=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Sun, 23 Jan 2022 17:33 UTC

In Forth you can write code generting words using by words like
POSTPONE COMPILE, and LITERAL. Standardized locals don't fit quite
in. While (LOCAL) has the superficial feel of a metaprogramming word,
it defines a named local and the only way to compile a read from or a
write to such a local is EVALUATE (with all the pitfalls one has to
work around). And you have to generate a unique name for the local
and then pass it to EVALUATE as a string.

So how could a metaprogramming interface for locals look like?

local-noname ( -- local-id ) ( generated code run-time: x -- )
defines a nameless local that is later referred to by the local-id
at run-time allocates space for the local an initializes it
flocal-noname ( -- local-id ) ( generated code run-time: r -- )
.... possibly more words for defining locals

read-local ( local-id -- ) ( generated code run-time: -- x )
at run-time, push the value of the local on the stack
fread-local ( local-id -- ) ( generated code run-time: -- r )
....
write-local ( local-id -- ) ( generated code run-time: x -- )
at run-time, change the value of the local to x
fwrite-local ( local-id -- ) ( generated code run-time: r -- )
....
or maybe have READ-LOCAL work for all kinds of local

You may wonder what the use of such words is. Here are two possible
scenarios:

1) You may want to deal with values in metaprogramming without these
values getting in the way on the data stack or the return stack (the
latter requires a system that can mix return stack and locals
accesses). E.g., many object-oriented packages have a THIS or SELF
value, with implicit usage of THIS in field (aka instance variable)
words. One can put the THIS value in a local, then store the local-id
somewhere, and use it when compiling the field references. This is of
course only a good solution if your THIS is only valid within a
definition (as in most OO packages, but not Bernd Paysan's).

2) When using Forth as intermediate language for compiling a different
source language, you may want to map the source language's locals into
Forth locals, but possibly not using the same names (because of
different scoping rules, or to avoid name collisions). So you would
generate a Forth local for every source local, store the local-ids of
the Forth locals in the symbol table, and compile source local
references into the appropriate READ-LOCAL or WRITE-LOCAL calls.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

Re: locals and metaprogramming

<ssn2c8$9li$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=16399&group=comp.lang.forth#16399

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ruvim.pi...@gmail.com (Ruvim)
Newsgroups: comp.lang.forth
Subject: Re: locals and metaprogramming
Date: Mon, 24 Jan 2022 23:32:06 +0300
Organization: A noiseless patient Spider
Lines: 101
Message-ID: <ssn2c8$9li$1@dont-email.me>
References: <2022Jan23.183317@mips.complang.tuwien.ac.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 24 Jan 2022 20:32:08 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="62941e22c00af87c14fcb5915cd7bf69";
logging-data="9906"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1941u8PtetVM4/WZX2rlcMe"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.0
Cancel-Lock: sha1:nVqMUPMWbTxaf06mCmTtiKnsKSA=
In-Reply-To: <2022Jan23.183317@mips.complang.tuwien.ac.at>
Content-Language: en-US
 by: Ruvim - Mon, 24 Jan 2022 20:32 UTC

On 2022-01-23 20:33, Anton Ertl wrote:
> In Forth you can write code generting words using by words like
> POSTPONE COMPILE, and LITERAL. Standardized locals don't fit quite
> in. While (LOCAL) has the superficial feel of a metaprogramming word,
> it defines a named local and the only way to compile a read from or a
> write to such a local is EVALUATE (with all the pitfalls one has to
> work around). And you have to generate a unique name for the local
> and then pass it to EVALUATE as a string.
>
> So how could a metaprogramming interface for locals look like?
>
> local-noname ( -- local-id ) ( generated code run-time: x -- )
> defines a nameless local that is later referred to by the local-id
> at run-time allocates space for the local an initializes it
> flocal-noname ( -- local-id ) ( generated code run-time: r -- )
> ... possibly more words for defining locals
>
> read-local ( local-id -- ) ( generated code run-time: -- x )
> at run-time, push the value of the local on the stack
> fread-local ( local-id -- ) ( generated code run-time: -- r )
> ...
> write-local ( local-id -- ) ( generated code run-time: x -- )
> at run-time, change the value of the local to x
> fwrite-local ( local-id -- ) ( generated code run-time: r -- )
> ...
> or maybe have READ-LOCAL work for all kinds of local

It looks like a reasonable approach since it provides a basis for the
Locals word set (i.e., it can be implemented on this basis).

When a local variable is used, its type is not provided along. The
system already knows the type of the variable. So type-specific
compilers are excessive.

Since these words is a basis for "(LOCAL)", a word for naming a local
variable can be also introduced. Probably, a system should be also
informed that all locals are declared in a definition [1].

So I can suggest the following set of words:

reserve-local ( -- local-id )
reserve-flocal ( -- local-id )
reserve-2local ( -- local-id )
fetch-local, ( local-id -- )
store-local, ( local-id -- )
enroll-local ( sd.name local-id -- )
finalize-locals ( -- )

For execution semantics of these words, an ambiguous condition exists if
the current definition is absent, or a local-id is consumed and the
current definition is not the one that was when the local-id was produced.

In this basis, "(local)" can be defined as follows:

: (local) ( sd.name -- )
dup if reserve-local enroll-local exit then
2drop finalize-locals
;

[1] Ideally I would prefer to have an ability to reserve a new local
variable in any place during compilation of a definition, and then
"finalize-locals" is not needed. But don't sure that it can be
implemented in any system that supports local variables.

> You may wonder what the use of such words is. Here are two possible
> scenarios:
>
> 1) You may want to deal with values in metaprogramming without these
> values getting in the way on the data stack or the return stack (the
> latter requires a system that can mix return stack and locals
> accesses). E.g., many object-oriented packages have a THIS or SELF
> value, with implicit usage of THIS in field (aka instance variable)
> words. One can put the THIS value in a local, then store the local-id
> somewhere, and use it when compiling the field references. This is of
> course only a good solution if your THIS is only valid within a
> definition (as in most OO packages, but not Bernd Paysan's).
>
> 2) When using Forth as intermediate language for compiling a different
> source language, you may want to map the source language's locals into
> Forth locals, but possibly not using the same names (because of
> different scoping rules, or to avoid name collisions). So you would
> generate a Forth local for every source local, store the local-ids of
> the Forth locals in the symbol table, and compile source local
> references into the appropriate READ-LOCAL or WRITE-LOCAL calls.

3) It's difficult to implement hygienic macros having local variables
(in a portable way, I mean). Using this basis it becomes not so difficult.

--
Ruvim

Re: locals and metaprogramming

<76c0cc27-c54f-4669-b5a1-cfc034137237n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=16409&group=comp.lang.forth#16409

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:a05:622a:1044:: with SMTP id f4mr10273916qte.635.1643102468831;
Tue, 25 Jan 2022 01:21:08 -0800 (PST)
X-Received: by 2002:ac8:7c4e:: with SMTP id o14mr15778845qtv.2.1643102468530;
Tue, 25 Jan 2022 01:21:08 -0800 (PST)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Tue, 25 Jan 2022 01:21:08 -0800 (PST)
In-Reply-To: <ssn2c8$9li$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=79.224.100.194; posting-account=AqNUYgoAAADmkK2pN-RKms8sww57W0Iw
NNTP-Posting-Host: 79.224.100.194
References: <2022Jan23.183317@mips.complang.tuwien.ac.at> <ssn2c8$9li$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <76c0cc27-c54f-4669-b5a1-cfc034137237n@googlegroups.com>
Subject: Re: locals and metaprogramming
From: minfo...@arcor.de (minf...@arcor.de)
Injection-Date: Tue, 25 Jan 2022 09:21:08 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 41
 by: minf...@arcor.de - Tue, 25 Jan 2022 09:21 UTC

Ruvim schrieb am Montag, 24. Januar 2022 um 21:32:11 UTC+1:
> On 2022-01-23 20:33, Anton Ertl wrote:
> > In Forth you can write code generting words using by words like
> > POSTPONE COMPILE, and LITERAL. Standardized locals don't fit quite
> > in. While (LOCAL) has the superficial feel of a metaprogramming word,
> > it defines a named local and the only way to compile a read from or a
> > write to such a local is EVALUATE (with all the pitfalls one has to
> > work around). And you have to generate a unique name for the local
> > and then pass it to EVALUATE as a string.
> >
> > So how could a metaprogramming interface for locals look like?
> >
> > local-noname ( -- local-id ) ( generated code run-time: x -- )
> > defines a nameless local that is later referred to by the local-id
> > at run-time allocates space for the local an initializes it
> > flocal-noname ( -- local-id ) ( generated code run-time: r -- )
> > ... possibly more words for defining locals
> >
> > read-local ( local-id -- ) ( generated code run-time: -- x )
> > at run-time, push the value of the local on the stack
> > fread-local ( local-id -- ) ( generated code run-time: -- r )
> > ...
> > write-local ( local-id -- ) ( generated code run-time: x -- )
> > at run-time, change the value of the local to x
> > fwrite-local ( local-id -- ) ( generated code run-time: r -- )
> > ...
> > or maybe have READ-LOCAL work for all kinds of local
> It looks like a reasonable approach since it provides a basis for the
> Locals word set (i.e., it can be implemented on this basis).
>
> When a local variable is used, its type is not provided along. The
> system already knows the type of the variable. So type-specific
> compilers are excessive.

Some Forth compilers support an extended locals syntax like
: FOO { f: fp-local -- } ... ;
to declare a floating-point local. TO will generate the associated
F! during compilation.

However for usable metacompilation of other languages, local
structs would probably be required too. But I don't know whether
eg gforth already supports local structs.

Re: locals and metaprogramming

<ssonnh$3l9$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=16411&group=comp.lang.forth#16411

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ruvim.pi...@gmail.com (Ruvim)
Newsgroups: comp.lang.forth
Subject: Re: locals and metaprogramming
Date: Tue, 25 Jan 2022 14:42:40 +0300
Organization: A noiseless patient Spider
Lines: 69
Message-ID: <ssonnh$3l9$1@dont-email.me>
References: <2022Jan23.183317@mips.complang.tuwien.ac.at>
<ssn2c8$9li$1@dont-email.me>
<76c0cc27-c54f-4669-b5a1-cfc034137237n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 25 Jan 2022 11:42:42 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="e3ed8f53564cdcc110f28c970fc4ca3e";
logging-data="3753"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+MlGroy0XwDkbX7dB44dcE"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.0
Cancel-Lock: sha1:n3tSXvNFh+MxdViCd1L+lV3IrSQ=
In-Reply-To: <76c0cc27-c54f-4669-b5a1-cfc034137237n@googlegroups.com>
Content-Language: en-US
 by: Ruvim - Tue, 25 Jan 2022 11:42 UTC

On 2022-01-25 12:21, minf...@arcor.de wrote:
> Ruvim schrieb am Montag, 24. Januar 2022 um 21:32:11 UTC+1:
>> On 2022-01-23 20:33, Anton Ertl wrote:
>>> In Forth you can write code generting words using by words like
>>> POSTPONE COMPILE, and LITERAL. Standardized locals don't fit quite
>>> in. While (LOCAL) has the superficial feel of a metaprogramming word,
>>> it defines a named local and the only way to compile a read from or a
>>> write to such a local is EVALUATE (with all the pitfalls one has to
>>> work around). And you have to generate a unique name for the local
>>> and then pass it to EVALUATE as a string.
>>>
>>> So how could a metaprogramming interface for locals look like?
>>>
>>> local-noname ( -- local-id ) ( generated code run-time: x -- )
>>> defines a nameless local that is later referred to by the local-id
>>> at run-time allocates space for the local an initializes it
>>> flocal-noname ( -- local-id ) ( generated code run-time: r -- )
>>> ... possibly more words for defining locals
>>>
>>> read-local ( local-id -- ) ( generated code run-time: -- x )
>>> at run-time, push the value of the local on the stack
>>> fread-local ( local-id -- ) ( generated code run-time: -- r )
>>> ...
>>> write-local ( local-id -- ) ( generated code run-time: x -- )
>>> at run-time, change the value of the local to x
>>> fwrite-local ( local-id -- ) ( generated code run-time: r -- )
>>> ...
>>> or maybe have READ-LOCAL work for all kinds of local
>> It looks like a reasonable approach since it provides a basis for the
>> Locals word set (i.e., it can be implemented on this basis).
>>
>> When a local variable is used, its type is not provided along. The
>> system already knows the type of the variable. So type-specific
>> compilers are excessive.
>
> Some Forth compilers support an extended locals syntax like
> : FOO { f: fp-local -- } ... ;
> to declare a floating-point local. TO will generate the associated
> F! during compilation.

By "compilers" above I refer the words that compiles some code. In
Anton's example they are type-specific: "read-local", "write-local",
"fread-local", "fwrite-local". My point is that these type-specific
words are excessive since the system knows the type for a local variable
in any way. In your example "TO fp-local" generates code to store a
float number. Hence, "TO" (and an underlying "compile-store-local")
knows that the "fp-local" is a float local variable.

> However for usable metacompilation of other languages, local
> structs would probably be required too. But I don't know whether
> eg gforth already supports local structs.

The syntax "name[ size ]" is supported by MPE/VfxForth, Gforth, SP-Forth.

https://gforth.org/manual/Gforth-locals.html
| Gforth supports the square bracket notation of local
| data structures. These locals are similar to
| variable-flavored locals, the size is specified as
| a constant expression. A declaration looks name[ size ].

SwiftForth supports local objects via "[objects ... objects]"

--
Ruvim

Re: locals and metaprogramming

<f884b07b-c872-4bb7-b91f-850f7c6bf9d5n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=16412&group=comp.lang.forth#16412

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:ac8:5889:: with SMTP id t9mr16081291qta.61.1643118152652;
Tue, 25 Jan 2022 05:42:32 -0800 (PST)
X-Received: by 2002:ae9:de41:: with SMTP id s62mr14844426qkf.188.1643118152449;
Tue, 25 Jan 2022 05:42:32 -0800 (PST)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Tue, 25 Jan 2022 05:42:32 -0800 (PST)
In-Reply-To: <ssonnh$3l9$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2003:f7:1f16:6f2c:885a:c715:56fd:739d;
posting-account=AqNUYgoAAADmkK2pN-RKms8sww57W0Iw
NNTP-Posting-Host: 2003:f7:1f16:6f2c:885a:c715:56fd:739d
References: <2022Jan23.183317@mips.complang.tuwien.ac.at> <ssn2c8$9li$1@dont-email.me>
<76c0cc27-c54f-4669-b5a1-cfc034137237n@googlegroups.com> <ssonnh$3l9$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <f884b07b-c872-4bb7-b91f-850f7c6bf9d5n@googlegroups.com>
Subject: Re: locals and metaprogramming
From: minfo...@arcor.de (minf...@arcor.de)
Injection-Date: Tue, 25 Jan 2022 13:42:32 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 53
 by: minf...@arcor.de - Tue, 25 Jan 2022 13:42 UTC

Ruvim schrieb am Dienstag, 25. Januar 2022 um 12:42:44 UTC+1:
> On 2022-01-25 12:21, minf...@arcor.de wrote:
> > Ruvim schrieb am Montag, 24. Januar 2022 um 21:32:11 UTC+1:
> >> On 2022-01-23 20:33, Anton Ertl wrote:
> >>> In Forth you can write code generting words using by words like
> >>> POSTPONE COMPILE, and LITERAL. Standardized locals don't fit quite
> >>> in. While (LOCAL) has the superficial feel of a metaprogramming word,
> >>> it defines a named local and the only way to compile a read from or a
> >>> write to such a local is EVALUATE (with all the pitfalls one has to
> >>> work around). And you have to generate a unique name for the local
> >>> and then pass it to EVALUATE as a string.
> >>>
> >>> So how could a metaprogramming interface for locals look like?
> >>>
> >>> local-noname ( -- local-id ) ( generated code run-time: x -- )
> >>> defines a nameless local that is later referred to by the local-id
> >>> at run-time allocates space for the local an initializes it
> >>> flocal-noname ( -- local-id ) ( generated code run-time: r -- )
> >>> ... possibly more words for defining locals
> >>>
> >>> read-local ( local-id -- ) ( generated code run-time: -- x )
> >>> at run-time, push the value of the local on the stack
> >>> fread-local ( local-id -- ) ( generated code run-time: -- r )
> >>> ...
> >>> write-local ( local-id -- ) ( generated code run-time: x -- )
> >>> at run-time, change the value of the local to x
> >>> fwrite-local ( local-id -- ) ( generated code run-time: r -- )
> >>> ...
> >>> or maybe have READ-LOCAL work for all kinds of local
> >> It looks like a reasonable approach since it provides a basis for the
> >> Locals word set (i.e., it can be implemented on this basis).
> >>
> >> When a local variable is used, its type is not provided along. The
> >> system already knows the type of the variable. So type-specific
> >> compilers are excessive.
> >
> > Some Forth compilers support an extended locals syntax like
> > : FOO { f: fp-local -- } ... ;
> > to declare a floating-point local. TO will generate the associated
> > F! during compilation.
> By "compilers" above I refer the words that compiles some code. In
> Anton's example they are type-specific: "read-local", "write-local",
> "fread-local", "fwrite-local". My point is that these type-specific
> words are excessive since the system knows the type for a local variable
> in any way. In your example "TO fp-local" generates code to store a
> float number. Hence, "TO" (and an underlying "compile-store-local")
> knows that the "fp-local" is a float local variable.

It is not necessary that the compiler uses type introspection to compile
read from a local _value_. Type information can be contained in the temporary
local identifier.

OTOH certainly TO is overloaded to be able to compile store to a local
value/fvalue/dvalue/structvalue.

Re: locals and metaprogramming

<ssp65e$d0p$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=16416&group=comp.lang.forth#16416

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ruvim.pi...@gmail.com (Ruvim)
Newsgroups: comp.lang.forth
Subject: Re: locals and metaprogramming
Date: Tue, 25 Jan 2022 18:49:00 +0300
Organization: A noiseless patient Spider
Lines: 83
Message-ID: <ssp65e$d0p$1@dont-email.me>
References: <2022Jan23.183317@mips.complang.tuwien.ac.at>
<ssn2c8$9li$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 25 Jan 2022 15:49:02 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="e3ed8f53564cdcc110f28c970fc4ca3e";
logging-data="13337"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1995EdDOnL+bTga50E9SaC6"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.0
Cancel-Lock: sha1:QboYLCVRtM2JBQdPbclpv9eltTU=
In-Reply-To: <ssn2c8$9li$1@dont-email.me>
Content-Language: en-US
 by: Ruvim - Tue, 25 Jan 2022 15:49 UTC

On 2022-01-24 23:32, Ruvim wrote:
[...]
> Since these words is a basis for "(LOCAL)", a word for naming a local
> variable can be also introduced. Probably, a system should be also
> informed that all locals are declared in a definition [1].
>
> So I can suggest the following set of words:
>
>   reserve-local  ( -- local-id )
>   reserve-flocal ( -- local-id )
>   reserve-2local ( -- local-id )
>   fetch-local, ( local-id -- )
>   store-local, ( local-id -- )
>   enroll-local ( sd.name local-id -- )
>   finalize-locals ( -- )
>
> For execution semantics of these words, an ambiguous condition exists if
> the current definition is absent, or a local-id is consumed and the
> current definition is not the one that was when the local-id was produced.
>
>
> In this basis, "(local)" can be defined as follows:
>
>   : (local) ( sd.name -- )
>     dup if reserve-local enroll-local exit then
>     2drop finalize-locals
>   ;
>
>
>
> [1] Ideally I would prefer to have an ability to reserve a new local
> variable in any place during compilation of a definition, and then
> "finalize-locals" is not needed. But don't sure that it can be
> implemented in any system that supports local variables.

In the use cases (1) and (3) (that are cited below) it's difficult to
correctly handle "finalize-locals", and moreover, in (3) a local
variable should be reservable in any place.

So "finalize-locals" goes contrary to the intended use, and hence it
should not be a part of the API. And if a system cannot allow to reserve
local variables in any place, then it probably should not provide this
API at all.

What do you think?

>> You may wonder what the use of such words is.  Here are two possible
>> scenarios:
>>
>> 1) You may want to deal with values in metaprogramming without these
>> values getting in the way on the data stack or the return stack (the
>> latter requires a system that can mix return stack and locals
>> accesses).  E.g., many object-oriented packages have a THIS or SELF
>> value, with implicit usage of THIS in field (aka instance variable)
>> words.  One can put the THIS value in a local, then store the local-id
>> somewhere, and use it when compiling the field references.  This is of
>> course only a good solution if your THIS is only valid within a
>> definition (as in most OO packages, but not Bernd Paysan's).
>>
>> 2) When using Forth as intermediate language for compiling a different
>> source language, you may want to map the source language's locals into
>> Forth locals, but possibly not using the same names (because of
>> different scoping rules, or to avoid name collisions).  So you would
>> generate a Forth local for every source local, store the local-ids of
>> the Forth locals in the symbol table, and compile source local
>> references into the appropriate READ-LOCAL or WRITE-LOCAL calls.
>
>
>
> 3) It's difficult to implement hygienic macros having local variables
> (in a portable way, I mean). Using this basis it becomes not so difficult.
>

--
Ruvim

1
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor