RfD - Enhanced local variable syntax (long)

[Stephen Pelc]

At long last I've started on my Forth200x tasks. Here's the first
cut of the enhanced local variables using the { ... } notation.

Stephen

RfD - Enhanced local variable syntax
====================================
Stephen Pelc - 20 August 2006

Problem
=======
1) The current LOCALS| ... | notation explicitly forces all locals
to be initialised from the data stack.
2) 1) The current LOCALS| ... | notation defines locals in reverse
order to the normal stack notation.
3) When programming large applications, especially those interfacing
with a host operating system, there is a frequent need for temporary
buffers.
4) Current implementations show that creation and destruction of
local buffers are much faster than using ALLOCATE (14.6.1.0707)
and FREE (14.6.1.1605).

Solution
========
Base version
------------
The following syntax for local arguments and local variables is
proposed. The sequence:
{ ni1 ni2 ... | lv1 lv2 ... -- o1 o2 }
defines local arguments, local variables, and outputs. The local
arguments are automatically initialised from the data stack on
entry, the rightmost being taken from the top of the data stack.
Local arguments and local variables can be referenced by name within
the word during compilation. The output names are dummies to allow
a complete stack comment to be generated.
The items between { and | are local arguments.
The items between | and -- are local variables or buffers.
The items between -- and } are outputs.

Local arguments and variables return their values when referenced,
and must be preceded by TO to perform a store.

Local buffers may be defined in the form:
arr[ <expr> ]
Any name ending in the '[' character will be treated as an buffer,
the expression up to the terminating ']' will be interpreted to
provide the size of the buffer. Local buffers only return their base
address, all operators such as TO generate an ambiguous condition.

In the example below, a and b are local arguments, a+b and a*b are
local variables, and arr[ is a 10 byte local buffer.

: foo { a b | a+b a*b arr[ 10 ] -- }
a b + to a+b
a b * to a*b
cr a+b . a*b .
arr[ 10 erase
s" Hello" arr[ swap cmove
;

Local types
-----------
Some current Forth systems use indicators to define local variables
of sizes other than a cell. It is proposed that any name ending in a
':'
(colon) be reserved for this use.

: foo { a b | F: f1 F: f2 -- c }
...
;

Discussion
==========
The '|' (ASCII 0x7C) character is widely used as the separator
between local arguments and local variables. Other characters
accepted in current Forth implementations are '\' (ASCII 0x5C) and
'Š' (ASCII 0xA6).. Since the ANS standard is defined in terms of
7 bit ASCII, and with regard to internationalistion, we propose only
to consider the '|' and '\' characters further. Only recognition of
the '|' separator is mandatory.

The use of local types is contentious as they only become useful
if TO is available for these. In practice, many current systems
permit TO to be used with floats (children of FVALUE) and other
data types. Such systems often provide additional operators such
as +TO (add from stack to item) for children of VALUE and FVALUE.
Standardisation of operators with (for example) floats needs to
be done before the local types extension can be incorporated into
Forth200x. Apart from forcing allocation of buffer space, no
additional functionality is provided by local types that cannot
be obtained using local buffers. More preparatory standardisation
needs to be done before local types.

Apart from { (brace) itself, the proposal introduces one new
word BUILDLV. The definition of this word is designed for future
enhancements, e.g. more local data types, without having to
introduce more new words.


Forth 200x text
===============

13.6.2.xxxx {
brace LOCAL EXT

Interpretation: Interpretation semantics for this word are undefined.

Compilation:
( "<spaces>arg1" ... "<spaces>argn" | "<spaces>lv1" ... "<spaces>lvn"
-- )

Create up to eight local arguments by repeatedly skipping leading
spaces, parsing arg, and executing 13.6.2.yyyy BUILDLV. The list of
local arguments to be defined is terminated by "|", "--" or "}".
Append the run-time semantics for local arguments given below to the
current definition. If a space delimited '|' is encountered, create
up to eight local variables or buffers by repeatedly skipping
leading spaces, parsing lv, and executing 13.6.2.yyyy BUILDLV. The
list of local variables and buffers to be defined is terminated by
"--" or "}". Append the run-time semantics for local variables and
local buffers given below to the current definition. If "--" has
been encountered, further text between "--" and } is ignored.

Local buffers have names that end in the '[' character. They define
their size by parsing the text string up to the next ']' character,
and passing that string to 7.6.1.1360 EVALUATE to obtain the size
of the storage in address units.

Local argument run-time: ( x1 ... xn -- )
Local variable run-time: ( -- )
Local buffer run-time: ( -- )

Initialize up to eight local arguments as described in 13.6.2.yyyy
BUILDLV. Local argument arg1 is initialized with x1, arg2 with x2 up
to argn from xn, which is on the top of the data stack. When
invoked, each local argument will return its value. The value
of a local argument may be changed using 13.6.1.2295 TO.

Initialize up to eight local variables or local buffers as described
in 13.6.2.yyyy BUILDLV. The initial contents of local variables and
local buffers are undefined. When invoked, each local variable
returns its value. The value of a local variable may be changed
using 13.6.1.2295 TO. The size of a local variable is a cell.
When invoked, each local buffer will return its address. The user
may make no assumption about the order and contiguity of local
variables and buffers in memory.

Ambiguous conditions:
The { ... } text extends over more than one line.
The expression for local buffer size does not return a single
cell.


13.6.2.yyyy BUILDLV
build-l-v LOCAL EXT

Interpretation: Interpretation semantics for this word are undefined.

Execution: ( c-addr u +n mode -- )
When executed during compilation, BUILDLV passes a message to the
system identifying a new local argument whose definition name is
given by the string of characters identified by c-addr u. The size
of the data item is given by +n address units, and the mode
identifies the construction required as follows:
0 - finish construction of initialisation and data storage
allocation code. C-addr and u are ignored. +n is 0
(other values are reserved for future use).
1 - identify a local argument, +n = cell
2 - identify a local variable, +n = cell
3 - identify a local buffer, +n = storage required.
4+ - reserved for future use
-ve - implementation specific values

The result of executing BUILDLV during compilation of a definition
is to create a set of named local arguments, variables and/or
buffers, each of which is a definition name, that only have
execution semantics within the scope of that definition's source.

local argument execution: ( -- x )
Push the local argument's value, x, onto the stack. The local
argument's value is initialized as described in 13.6.2.xxxx { and may
be
changed by preceding the local argument's name with TO.

local variable execution: ( -- x )
Push the local variables's value, x, onto the stack. The local
variable is not initialised. The local variable's value may be
changed by preceding the local variable's name with TO.

local buffer execution: ( -- a-addr )
Push the local buffer's address, a-addr, onto the stack. The address
is aligned as in 3.3.3.1. The contents of the buffer are not
initialised.

Note: This word does not have special compilation semantics in the
usual sense because it provides access to a system capability for
use by other user-defined words that do have them. However, the
locals facility as a whole and the sequence of messages passed
defines specific usage rules with semantic implications that are
described in detail in section 13.3.3 Processing locals.

Note: This word is not intended for direct use in a definition to
declare that definition's locals. It is instead used by system or
user compiling words. These compiling words in turn define their
own syntax, and may be used directly in definitions to declare
locals. In this context, the syntax for BUILDLV is defined in terms
of a sequence of compile-time messages and is described in detail
in section 13.3.3 Processing locals.

Note: The LOCAL EXT word set modifies the syntax and semantics of
6.2.2295 TO as defined in the Core Extensions word set.

See: 3.4 The Forth text interpreter

Ambiguous conditions:
a local argument, variable or buffer is executed while in
interpretation state.


Reference implementation
=========================
(currently untested)

: TOKEN \ -- caddr u
\ Get the next space delimited token from the input stream.
BL PARSE
;

: LTERM? \ caddr u -- flag
\ Return true if the string caddr/u is "--" or "}"
2dup s" --" compare 0= >r
s" }" compare 0= r> or
;

: LBSIZE \ -- +n
\ Parse up to the terminating ']' and EVALUATE the expression
\ not including the terminating ']'.
[char] ] parse evaluate

: LB? \ caddr u -- flag
\ Return true if the last character of the string is '['.
+ 1 chars - c@ [char} [ =
;

: LSEP? \ caddr u -- flag
\ Return true if the string caddr/u is the separator between
\ local arguments and local variables or buffers.
2dup s" |" compare 0= >r
s" \" compare 0= r> or
;

: { ( -- )
0 >R \ indicate arguments
BEGIN
TOKEN 2DUP LTERM? 0=
WHILE \ -- caddr len
2DUP LSEP? IF \ if '|'
R> DROP 1 >R \ change to vars and buffers
ELSE
R@ 0= IF \ argument?
CELL 1
ELSE \ variable or buffer
LB?
IF LBSIZE 3 ELSE CELL 2 THEN
THEN
BUILDLV
THEN
REPEAT
BEGIN
S" }" COMPARE
WHILE
TOKEN
REPEAT
0 0 0 0 BUILDLV
R> DROP
; IMMEDIATE

[t***@gmail.com]

Post by Stephen Pelc
At long last I've started on my Forth200x tasks. Here's the first
cut of the enhanced local variables using the { ... } notation.
Stephen
RfD - Enhanced local variable syntax
====================================
Stephen Pelc - 20 August 2006
Problem
=======
1) The current LOCALS| ... | notation explicitly forces all locals
to be initialised from the data stack.
2) 1) The current LOCALS| ... | notation defines locals in reverse
order to the normal stack notation.
3) When programming large applications, especially those interfacing
with a host operating system, there is a frequent need for temporary
buffers.
4) Current implementations show that creation and destruction of
local buffers are much faster than using ALLOCATE (14.6.1.0707)
and FREE (14.6.1.1605).
Solution
========
Base version
------------
The following syntax for local arguments and local variables is
{ ni1 ni2 ... | lv1 lv2 ... -- o1 o2 }
defines local arguments, local variables, and outputs. The local
arguments are automatically initialised from the data stack on
entry, the rightmost being taken from the top of the data stack.
Local arguments and local variables can be referenced by name within
the word during compilation. The output names are dummies to allow
a complete stack comment to be generated.
The items between { and | are local arguments.
The items between | and -- are local variables or buffers.
The items between -- and } are outputs.

[snip]

Intersting. I've been slowly working on a Forth-based lanaguage in
which I aquire local variables using slightly different notation. To
reuse your example, essentially:

: foo
'b 'a
a' b' + 'a+b
a' b' * 'a*b
cr a+b' . a*b' .
;

Such that 'var pops the value off the stack and stores it. And var'
puts the value (or actually a reference to the value) back onto the
stack. Yes, the initial stores are backward but I don;t find that too
problematic.

I have not consider the treatment of fixed sized buffers however.

~Trans.

P.S. I am still relatively new to Forth.

[Andreas Kochenburger]

Post by Stephen Pelc
The following syntax for local arguments and local variables is
{ ni1 ni2 ... | lv1 lv2 ... -- o1 o2 }
defines local arguments, local variables, and outputs. The local
arguments are automatically initialised from the data stack on
entry, the rightmost being taken from the top of the data stack.
Local arguments and local variables can be referenced by name within
the word during compilation. The output names are dummies to allow
a complete stack comment to be generated.
The items between { and | are local arguments.
The items between | and -- are local variables or buffers.
The items between -- and } are outputs.

Some Forths use curly braces for multiline comments. instead of the
ugly 0 [IF]
I am comfortable with L( ... ) for defining locals. Also it resembles
the stack annotation. And as other posted, braces are hard to read.

I see problems with output locals. In my previous experiments I
noticed that they were seldom of practical use.
: TEST L( a -- o1 o2 )
a to o1
1
a 2 + to o2 ;
0 TEST
Will the output be 1 0 2 or 0 2 1 ?


Andreas
-------
A computer is like an old Greek god, with a lot of rules and no mercy.

[Stephen Pelc]

On Mon, 21 Aug 2006 09:03:46 +0200, Andreas Kochenburger

Post by Andreas Kochenburger
Some Forths use curly braces for multiline comments. instead of the
ugly 0 [IF]

The interpretation semantics of { are undefined. The use of { for
comments was introduced by Forth Inc after the locals { as far as
I know. Their usage is always during interpretation. As far as
language lawyers are concerned, their is no conflict!

Post by Andreas Kochenburger
I am comfortable with L( ... ) for defining locals. Also it resembles
the stack annotation. And as other posted, braces are hard to read.

Existing practice in VFX Forth, Win32Forth, gForth and others
over many years is convincing.

Post by Andreas Kochenburger
I see problems with output locals. In my previous experiments I
noticed that they were seldom of practical use.

Everything after '--' is discarded and ignored. It's defined
so that formal comments can be used. I'll update the text.

Stephen

[Andreas Kochenburger]

Post by Stephen Pelc
Everything after '--' is discarded and ignored. It's defined
so that formal comments can be used. I'll update the text.

Then everything after -- is comment. IMHO one should not mix
unnecessarily compiler instructions and comments within the same
syntax. You could put any misleading things after --.
Andreas
-------
A computer is like an old Greek god, with a lot of rules and no mercy.

[Stephen Pelc]

On Tue, 22 Aug 2006 08:48:21 +0200, Andreas Kochenburger

Post by Andreas Kochenburger
Then everything after -- is comment. IMHO one should not mix
unnecessarily compiler instructions and comments within the same
syntax. You could put any misleading things after --.

It is very common practice to put a stack comment on the definition
line of a word.

: foo ( a b c | e f -- d }
\ *G FOO does something useful

Modern systems, e.g. DocGen and Brad Eckert's DexH extension,
can use this line to produce documentation. We do not
want such systems to have to provide two lines with the
same information

: foo \ a b c -- d
\ *G FOO does something useful
( a b c | e f -- d }

Having two definitions of the same thing is a recipe for error.
Enabling the tail after '--' saves keystrokes. Note that '--'
is not mandatory.

Stephen

[dbu]

Post by Stephen Pelc
At long last I've started on my Forth200x tasks. Here's the first
cut of the enhanced local variables using the { ... } notation.
SNIP <
Discussion
==========
The '|' (ASCII 0x7C) character is widely used as the separator
between local arguments and local variables. Other characters
accepted in current Forth implementations are '\' (ASCII 0x5C) and
'¦' (ASCII 0xA6).. Since the ANS standard is defined in terms of
7 bit ASCII, and with regard to internationalistion, we propose only
to consider the '|' and '\' characters further. Only recognition of
the '|' separator is mandatory.

Win32Forth support's both '|' and '\'.

regards
Dirk Busch

[Alex McDonald]

Post by Stephen Pelc
At long last I've started on my Forth200x tasks. Here's the first
cut of the enhanced local variables using the { ... } notation.

Coincidentally, I have been working on the locals implementation in the
W32F native code version this last week. Timely; thank you.

Post by Stephen Pelc
Stephen
RfD - Enhanced local variable syntax
====================================
Stephen Pelc - 20 August 2006
Problem
=======
1) The current LOCALS| ... | notation explicitly forces all locals
to be initialised from the data stack.
2) 1) The current LOCALS| ... | notation defines locals in reverse
order to the normal stack notation.
3) When programming large applications, especially those interfacing
with a host operating system, there is a frequent need for temporary
buffers.
4) Current implementations show that creation and destruction of
local buffers are much faster than using ALLOCATE (14.6.1.0707)
and FREE (14.6.1.1605).

Agree with the above, and would add

5) Current implementations of { are diverging in the facilities they
provide.
6) { and } are visually confusing. Perhaps select another character or
string, which would allow existing implementations to do their own
thing unmolested.

Post by Stephen Pelc
Solution
========
Base version
------------
The following syntax for local arguments and local variables is
{ ni1 ni2 ... | lv1 lv2 ... -- o1 o2 }
defines local arguments, local variables, and outputs. The local
arguments are automatically initialised from the data stack on
entry, the rightmost being taken from the top of the data stack.
Local arguments and local variables can be referenced by name within
the word during compilation. The output names are dummies to allow
a complete stack comment to be generated.

IMHO the locals should really not replace the stack commentary (and
perhaps it's time there was an RFD for those too that can replace { }
?). The maximal requirement should be

{ ni1 ni2 ... | lv1 lv2 ... }

otherwise dummies may be taken for real values (and I also prefer the
word values to variables above to avoid ambiguity). They're suggestive
of automatic return values, which they are not.

Post by Stephen Pelc
The items between { and | are local arguments.
The items between | and -- are local variables or buffers.
The items between -- and } are outputs.
Local arguments and variables return their values when referenced,
and must be preceded by TO to perform a store.

That's the bit I hate, but it's too late to argue for local variables I
know.

Post by Stephen Pelc
arr[ <expr> ]
Any name ending in the '[' character will be treated as an buffer,
the expression up to the terminating ']' will be interpreted to
provide the size of the buffer. Local buffers only return their base
address, all operators such as TO generate an ambiguous condition.

I do like the idea of being able to declare variables as opposed to
values.

I don't like the requirement to have a special token recogniser in the
parse a for the [ on grounds of aesthetics if nothing else. Plus, other
syntaxes can be envisaged in which a modified EVALUATE/QUIT with a
minor modification can handle the string between { and } in compile
mode; DPANS section 3.4 clause "d) If unsuccessful, an ambiguous
condition exists" would be "d) if unsuccesful, declare a local cell
sized value". It also makes f: or float: and other type modifiers
supportable as parsing immediate words.

So, does the [ have to be part of the name? Here's a parsing example;

{ a
[ 10 ] buffer: b
float: f
variable: v
| value: c }

Question: is this

: x [ 128 ] { a arr[ ] } ;

valid? And is this

128 : X { a arr[ ] } ;

ambiguous or invalid?

[A note. In Forths like W32F that have a MOPS based OOP, [ is becoming
overworked as it is also used for late binding. I can see potentially
ambiguous situations should locals be extended to include objects.
That, however, is a problem for another discusssion.]

Post by Stephen Pelc
In the example below, a and b are local arguments, a+b and a*b are
local variables, and arr[ is a 10 byte local buffer.
: foo { a b | a+b a*b arr[ 10 ] -- }
a b + to a+b
a b * to a*b
cr a+b . a*b .
arr[ 10 erase
s" Hello" arr[ swap cmove

Ouch. That [ really grates.

Post by Stephen Pelc
;
Local types
-----------
Some current Forth systems use indicators to define local variables
of sizes other than a cell. It is proposed that any name ending in a
':'
(colon) be reserved for this use.
: foo { a b | F: f1 F: f2 -- c }
...
;
Discussion
==========
The '|' (ASCII 0x7C) character is widely used as the separator
between local arguments and local variables. Other characters
accepted in current Forth implementations are '\' (ASCII 0x5C) and
'¦' (ASCII 0xA6).. Since the ANS standard is defined in terms of
7 bit ASCII, and with regard to internationalistion, we propose only
to consider the '|' and '\' characters further. Only recognition of
the '|' separator is mandatory.

Use of \ should be discouraged on the grounds of ambiguity. It also
gives parsing & colouring editors indigestion. 0xA6 is outside the
range of ASCII.

[snipped]

Post by Stephen Pelc
0 0 0 0 BUILDLV

Is 0 0 (LOCALS) an equivalent?

[Alex McDonald]

Post by Alex McDonald

Post by Stephen Pelc
At long last I've started on my Forth200x tasks. Here's the first
cut of the enhanced local variables using the { ... } notation.

Coincidentally, I have been working on the locals implementation in the
W32F native code version this last week. Timely; thank you.

Post by Stephen Pelc
Stephen
RfD - Enhanced local variable syntax
====================================
Stephen Pelc - 20 August 2006
Problem
=======
1) The current LOCALS| ... | notation explicitly forces all locals
to be initialised from the data stack.
2) 1) The current LOCALS| ... | notation defines locals in reverse
order to the normal stack notation.
3) When programming large applications, especially those interfacing
with a host operating system, there is a frequent need for temporary
buffers.
4) Current implementations show that creation and destruction of
local buffers are much faster than using ALLOCATE (14.6.1.0707)
and FREE (14.6.1.1605).

Agree with the above, and would add
5) Current implementations of { are diverging in the facilities they
provide.
6) { and } are visually confusing. Perhaps select another character or
string, which would allow existing implementations to do their own
thing unmolested.

And;

7) LOCALS| has the following restrictions on the use of the rstack;

13.3.3.2 Syntax restrictions
c) Locals shall not be declared until values previously placed on the
return stack within the definition have been removed;
d) After a definition's locals have been declared, a program may place
data on the return stack. However, if this is done, locals shall not be
accessed until those values have been removed from the return stack;

Can this restriction be lifted with { locals? W32F has no such
restriction, although the current implementation is not optimal. W32F
keeps an rstack base pointer at run time as it supports variable length
locals, something that isn't really required and isn't proposed in ths
RfD.

It's only an issue for implementations that use the rstack for locals;
for them, removing this restriction would simply require r> >r 2>r and
2r> to communicate to the locals at compile time what they're doing
with the return stack.

[Stephen Pelc]

On 21 Aug 2006 16:04:53 -0700, "Alex McDonald"

Post by Alex McDonald

Post by Alex McDonald
Agree with the above, and would add
5) Current implementations of { are diverging in the facilities they
provide.

It's the function of a standard to encourage people to use the
same names for the same function, but it is not the purpose to
stop new facilities being added to implementations.

Post by Alex McDonald

Post by Alex McDonald
6) { and } are visually confusing. Perhaps select another character or
string, which would allow existing implementations to do their own
thing unmolested.

Common practice is to use { ... }. Is changing a name in common use
because we need new glasses or bigger monitors good enough reason
for change?

Post by Alex McDonald
7) LOCALS| has the following restrictions on the use of the rstack;
13.3.3.2 Syntax restrictions
c) Locals shall not be declared until values previously placed on the
return stack within the definition have been removed;

Removing this restriction would break code. I will add it.

Post by Alex McDonald
d) After a definition's locals have been declared, a program may place
data on the return stack. However, if this is done, locals shall not be
accessed until those values have been removed from the return stack;

Do any current systems suffer if this restriction is removed?
Implementers please respond! Current MPE systems will not suffer
unless { ... } is used a second time - should this be an ambiguous
condition?

Similarly, many current systesms, including MPE's, will break
if { ... } is used inside a control structure, e.g.

: foo \ ...
... if
{ a b c -- }
...
else
...
then
;

I propose to add this as an amiguous condition as below.

Ambiguous conditions:
a) The { ... } text extends over more than one line.
b) The expression for local buffer size does not return a single
cell.
c) { ... } shall not be declared until values previously placed
on the return stack within the definition have been removed.
d) { ... } is declared within a control structure.

Stephen

[Anton Ertl]

Post by Stephen Pelc
On 21 Aug 2006 16:04:53 -0700, "Alex McDonald"

[Stephen Pelc]

Post by Stephen Pelc

Post by Alex McDonald

Post by Alex McDonald
6) { and } are visually confusing. Perhaps select another character or
string, which would allow existing implementations to do their own
thing unmolested.

Common practice is to use { ... }. Is changing a name in common use
because we need new glasses or bigger monitors good enough reason
for change?

No. Anoter solution to the glasses problem is to use a colouring
editor. E.g., Emacs with gforth.el colours Forth comments in red by
default, and locals declarations in beige.

Post by Stephen Pelc

Post by Alex McDonald
7) LOCALS| has the following restrictions on the use of the rstack;
13.3.3.2 Syntax restrictions
c) Locals shall not be declared until values previously placed on the
return stack within the definition have been removed;

Removing this restriction would break code. I will add it.

No need to. This is a general restriction on locals, not on LOCALS|.
It also applies to locals defined through (LOCAL).

Also I don't see that removing this restriction would break existing
programs, whether standard or not: Standard programs don't go there,
and I doubt that there are non-standard programs that rely on any
particular behaviour in that area. It might require changes to some
systems, though.

Post by Stephen Pelc

Post by Alex McDonald
d) After a definition's locals have been declared, a program may place
data on the return stack. However, if this is done, locals shall not be
accessed until those values have been removed from the return stack;

Do any current systems suffer if this restriction is removed?

Not Gforth. Gforth also does not have the restriction above.

Post by Stephen Pelc
Implementers please respond! Current MPE systems will not suffer
unless { ... } is used a second time - should this be an ambiguous
condition?

It is already.

However, I find it very practical to be able to use { ... } several
times, rather than having to declare locals in places where I don't
have a value for them, and then using TO when I have a value for them.

Post by Stephen Pelc
Similarly, many current systesms, including MPE's, will break
if { ... } is used inside a control structure, e.g.
: foo \ ...
... if
{ a b c -- }
...
else
...
then
;
I propose to add this as an amiguous condition as below.

It is already (13.3.3.2 b).

Followups set to c.l.f.

- anton

[Andreas Kochenburger]

On 21 Aug 2006 16:04:53 -0700, "Alex McDonald"

Post by Alex McDonald
c) Locals shall not be declared until values previously placed on the
return stack within the definition have been removed;

I'd prefer that the locals definition must be the first definition
within a word, i.e. appear right after : NAME ..
This can easily be checked by the compiler.

Post by Alex McDonald
d) After a definition's locals have been declared, a program may place
data on the return stack. However, if this is done, locals shall not be
accessed until those values have been removed from the return stack;

This is an unnecessary and contraproductive restriction. I'd consider
such locals implementations seriously flawed.


Andreas
-------
1 + 1 = 3, for large values of 1.

[Alex McDonald]

Post by Stephen Pelc
On 21 Aug 2006 16:04:53 -0700, "Alex McDonald"

Post by Alex McDonald
c) Locals shall not be declared until values previously placed on the
return stack within the definition have been removed;

I'd prefer that the locals definition must be the first definition
within a word, i.e. appear right after : NAME ..
This can easily be checked by the compiler.

It can't be parsed for as it would break a lot of code. It can be
detected only if { can ascertain that there's been no code generated
between : and { . Would that not give optimising compilers some
difficulties?

[J Thomas]

Post by Alex McDonald

Post by Andreas Kochenburger
I'd prefer that the locals definition must be the first definition
within a word, i.e. appear right after : NAME ..
This can easily be checked by the compiler.

It can't be parsed for as it would break a lot of code. It can be
detected only if { can ascertain that there's been no code generated
between : and { . Would that not give optimising compilers some
difficulties?

If you want to check for that, you could have { be something that :
:NONAME and DOES> check. Any other time it doesn't work or gives an
error message.

It wouldn't break code for the standard to say not to define locals
elsewhere -- code which does that would be just as portable as it is
now. Any implementator who wants to let people define locals elsewhere
could do so. The question is whether it would be good to require
implementors to allow locals definition elsewhere. And if so, which
places should locals definition be allowed?

Good optimising compilers will put locals in available registers and
will only move them out of the registers when the registers must be
used for something else -- for example a called word that uses locals,
or a word in another task that uses locals.

But less-optimised Forths will tend to put locals on the return stack,
and if they do there's a question what other return-stack uses might
interfere with locals or vice versa. What I remember for that is direct
use of the return stack ( >R etc), loops, and calls. Calls are no
problem, you won't use your locals inside a word you call and the
return stack will be clean when that word returns.

Implementations that call a deeper routine when they switch to compile
state are already nonstandard so that shouldn't be a problem.

: ]FOO .... local1 ] local2 .... ;

: TEST [ do-something ]FOO ; ought to work just fine.

[Anton Ertl]

Post by J Thomas

Post by Alex McDonald

Post by Andreas Kochenburger
I'd prefer that the locals definition must be the first definition
within a word, i.e. appear right after : NAME ..
This can easily be checked by the compiler.

It can't be parsed for as it would break a lot of code. It can be
detected only if { can ascertain that there's been no code generated
between : and { . Would that not give optimising compilers some
difficulties?

:NONAME and DOES> check. Any other time it doesn't work or gives an
error message.
It wouldn't break code for the standard to say not to define locals
elsewhere -- code which does that would be just as portable as it is
now. Any implementator who wants to let people define locals elsewhere
could do so. The question is whether it would be good to require
implementors to allow locals definition elsewhere. And if so, which
places should locals definition be allowed?

Why should {-locals be more restricted than LOCALS|-locals?

Currently a standard programs can use LOCALS| in other places, or it
can load http://www.complang.tuwien.ac.at/forth/anslocal.fs and use {
in the same places.

If Andreas Kochenburg only wants to use { at the start of a
definition, there is nothing in this proposal that prevents him from
doing so. Imposing this practice on others smells of Adaism.

Fup2: c.l.f

- anton

[GerryJ]

Post by Stephen Pelc
Local arguments and variables return their values when referenced,
and must be preceded by TO to perform a store.

If we're having local variables, why can't they leave their address on
the stack so that @ and ! etc can be used as with global variables
instead of TO. I would have thought consistency with globals was a
definite thing to aim for.

Gerry

[Stephen Pelc]

On 21 Aug 2006 06:24:38 -0700, "GerryJ"

Post by GerryJ

Post by Stephen Pelc
Local arguments and variables return their values when referenced,
and must be preceded by TO to perform a store.

If we're having local variables, why can't they leave their address on
instead of TO. I would have thought consistency with globals was a
definite thing to aim for.

Because that's what happens with LOCALS| ... | and it's common
practice in all current { ... } implementations.

Stephen

[jacko]

Post by Stephen Pelc
On 21 Aug 2006 06:24:38 -0700, "GerryJ"

Post by GerryJ

Post by Stephen Pelc
Local arguments and variables return their values when referenced,
and must be preceded by TO to perform a store.

If we're having local variables, why can't they leave their address on
instead of TO. I would have thought consistency with globals was a
definite thing to aim for.

Because that's what happens with LOCALS| ... | and it's common
practice in all current { ... } implementations.

a change in syntax, but yet a requirement to have an easy search and
replace?? umm
any implementation should provide a simple textual replace definition
too to replace all the old standard syntax?

personally i don't need names for locals, just a fixed base or top for
referancing numbers from, as use of too many locals usualy indicates
little factorization.

a better soulution would maybe to concentrate on giving words names,
which do not interfere with global names.

eg

: %localfn ... ;

or some other standardized local prefix.

ooh we just love stack frames :-) , so i suppose a C calling convention
would be best :-)

cheers

[GerryJ]

Post by Stephen Pelc
On 21 Aug 2006 06:24:38 -0700, "GerryJ"

Post by GerryJ

Post by Stephen Pelc
Local arguments and variables return their values when referenced,
and must be preceded by TO to perform a store.

If we're having local variables, why can't they leave their address on
instead of TO. I would have thought consistency with globals was a
definite thing to aim for.

Because that's what happens with LOCALS| ... | and it's common
practice in all current { ... } implementations.

I'm well aware of that. I suppose I'm just quibbling about calling them
local variables, calling them local values would remove any
inconsistency with global variables. Why introduce inconsistency if it
can be avoided?

Gerry

[Coos Haak]

Post by GerryJ

Post by Stephen Pelc
Local arguments and variables return their values when referenced,
and must be preceded by TO to perform a store.

If we're having local variables, why can't they leave their address on
instead of TO. I would have thought consistency with globals was a
definite thing to aim for.
Gerry

Consider that in some implementations the stacks are not directly
accessible. For example : EMIT SP@ 1 EMIT DROP ; does not work there.
Value-type locals are portable everywhere.
My 16-bit implementation has a separate section (segment in x86 parlance)
for the three stacks (data, return and locals).

[Bernd Paysan]

Post by Stephen Pelc
Local types
-----------
Some current Forth systems use indicators to define local variables
of sizes other than a cell. It is proposed that any name ending in a
':'
(colon) be reserved for this use.
: foo  { a b | F: f1 F: f2 -- c }
...
;

IMHO, the typed locals are quite important, and can offer a way to be used
for more complex locals (like structures and other sort of temporary
buffers).

In bigFORTH, I've the following types:

W: normal word, the default if no type is selected
F: floating point number
D: double number
R: Record. Usage R: <record_name> <local>. Records are always uninitialized.

I think this is universal. Whatever buffer you need, you can always define a
structure/record for it, and declare a local to hold it.

[Anton Ertl]

Post by Stephen Pelc
Local types
-----------
Some current Forth systems use indicators to define local variables
of sizes other than a cell. It is proposed that any name ending in a
':'
(colon) be reserved for this use.
: foo { a b | F: f1 F: f2 -- c }
...
;

I actually would like to see F: (and maybe D:) in your proposal. They
are implemented in at least two systems (Gforth and BigForth), and
even though I am not a heavy FP user, I have used them a number of
times; in comparison, the need for local buffers was never big enough
for me to implement them.

Of course, we can also do these words in another proposal, but while
you are at it, you might as well include them now.

Post by Stephen Pelc
The use of local types is contentious as they only become useful
if TO is available for these. In practice, many current systems
permit TO to be used with floats (children of FVALUE) and other
data types. Such systems often provide additional operators such
as +TO (add from stack to item) for children of VALUE and FVALUE.

Gforth has TO for F: locals, but neither FVALUE nor +TO (and I have
never seen the need), so I think it's not a good idea to bundle these.

Post by Stephen Pelc
Standardisation of operators with (for example) floats needs to
be done before the local types extension can be incorporated into
Forth200x. Apart from forcing allocation of buffer space, no
additional functionality is provided by local types that cannot
be obtained using local buffers.

An F: local behaves VALUE-like. A local buffer does not.

Post by Stephen Pelc
More preparatory standardisation
needs to be done before local types.

I don't follow that. One can and should define the extension to TO at
the same time as F:, just as the extension to TO for locals is defined
in the smame section (13.6.1) as locals.

Post by Stephen Pelc
Forth 200x text
===============
13.6.2.xxxx {
brace LOCAL EXT
Interpretation: Interpretation semantics for this word are undefined.
( "<spaces>arg1" ... "<spaces>argn" | "<spaces>lv1" ... "<spaces>lvn"
-- )
Create up to eight

Leave the "up to eight" away everywhere. This restriction is already
defined in 13.3.3.2 f. Repeating it everywhere is just bad style
(Sure, this is done in 13.6.2.1795, but that specification is just as
bad as the word it specifies). Also, with your definition, one might
think that one can have 8 locals before the | and 8 locals after.

Post by Stephen Pelc
local arguments by repeatedly skipping leading
spaces, parsing arg, and executing 13.6.2.yyyy BUILDLV. The list of
local arguments to be defined is terminated by "|", "--" or "}".
Append the run-time semantics for local arguments given below to the
current definition. If a space delimited '|' is encountered, create
up to eight local variables or buffers by repeatedly skipping
leading spaces, parsing lv, and executing 13.6.2.yyyy BUILDLV. The

^^
Undefined word.

Post by Stephen Pelc
Local buffers have names that end in the '[' character. They define
their size by parsing the text string up to the next ']' character,
and passing that string to 7.6.1.1360 EVALUATE to obtain the size
of the storage in address units.

I would prefer a more procedural formulation. It is unclear when
things happen. Does the EVALUATE happen at compile time? Is the
order of the EVALUATEs of several local buffers defined? The
possibilities for the stack effect of this code are not defined. Can
it take arguments from the stack?

Post by Stephen Pelc
Local argument run-time: ( x1 ... xn -- )
Local variable run-time: ( -- )

"local value" or just "local" might be a little clearer, as someone
else has remarked.

Post by Stephen Pelc
Local buffer run-time: ( -- )

This is confusing and out of line with the rest of the standard. What
you are defining here is the run-time semantics of {. This should
just be labeled "Run-time:".

Post by Stephen Pelc
Initialize up to eight local arguments as described in 13.6.2.yyyy
BUILDLV. Local argument arg1 is initialized with x1, arg2 with x2 up
to argn from xn, which is on the top of the data stack. When
invoked, each local argument will return its value. The value
of a local argument may be changed using 13.6.1.2295 TO.
Initialize up to eight local variables or local buffers as described
in 13.6.2.yyyy BUILDLV. The initial contents of local variables and
local buffers are undefined. When invoked, each local variable
returns its value. The value of a local variable may be changed
using 13.6.1.2295 TO. The size of a local variable is a cell.
When invoked, each local buffer will return its address.

The "when invoked" sentences are the locals' execution semantics and
should be specified in the specification of BUILDLV.

Post by Stephen Pelc
The user
may make no assumption about the order and contiguity of local
variables and buffers in memory.

The standard is concerned with programs, not users. Maybe just write
"A local buffers is a contiguous region, but not contiguous with any
other memory".

Post by Stephen Pelc
The { ... } text extends over more than one line.

For how many systems is this a problem. It's not for Gforth, but it
is for the http://www.complang.tuwien.ac.at/forth/anslocal.fs
implementation.

Post by Stephen Pelc
The expression for local buffer size does not return a single
cell.

Maybe: "The evalutation of the string for the local buffer size does
not have the stack effect ( -- u )".

Post by Stephen Pelc
13.6.2.yyyy BUILDLV

This word is used rarely, so we can afford a longer, less cryptic
name. How about BUILD-LOCAL?

Post by Stephen Pelc
build-l-v LOCAL EXT
Interpretation: Interpretation semantics for this word are undefined.
Execution: ( c-addr u +n mode -- )
When executed during compilation, BUILDLV passes a message to the
system

This "passes a message" formulation is also out of style for the
standard, but then we probably should also fix (LOCAL).

identifying a new local argument whose definition name is

Post by Stephen Pelc
given by the string of characters identified by c-addr u. The size
of the data item is given by +n address units, and the mode
0 - finish construction of initialisation and data storage
allocation code. C-addr and u are ignored. +n is 0
(other values are reserved for future use).
1 - identify a local argument, +n = cell

"1 cells" instead of "cell"?

Post by Stephen Pelc
2 - identify a local variable, +n = cell
3 - identify a local buffer, +n = storage required.
4+ - reserved for future use
-ve - implementation specific values

This seems to be the usual nonsense of specifying immensely
complicated words for the sake of minimizing the number of names (and
in practice, the names will be introduced through factoring when
implementing this word anyway). How about using several words for
these purposes:

We already have (LOCAL) for local arguments and for termination. We
can also use it for local variables (then the program/wrapper has to
provide a dummy value). For local buffers we could add (LOCAL-BUFFER)
( c-addr u +n -- ). Hey, we even managed to have the same number of
names as with the complicated BUILDLV, but they are simpler.

Post by Stephen Pelc
The result of executing BUILDLV during compilation of a definition
is to create a set of named local arguments, variables and/or
buffers, each of which is a definition name, that only have
execution semantics within the scope of that definition's source.

The "only have execution semantics" is nonsense; just leave it away.
The important issue is that they are only visible up to the end of the
definition, but that's already mentioned in 13.3.3.1 a.

Post by Stephen Pelc
local buffer execution: ( -- a-addr )
Push the local buffer's address, a-addr, onto the stack. The address
is aligned as in 3.3.3.1. The contents of the buffer are not
initialised.

You have to specify that the buffer (and its address) lives only until
the colon definition containing the local buffer definition is left,
in whatever way.

As for the alignment, you may want to specify 12.3.1.1 (FP aligned)
instead of or in addition to 3.3.3.1. Having to FALIGN the buffer
when putting a float in it sucks.

Fup2: c.l.f

- anton

[Doug Hoffman]

Post by Stephen Pelc
At long last I've started on my Forth200x tasks. Here's the first
cut of the enhanced local variables using the { ... } notation.

Nicely done and long overdue, IMO. Thank you.

Neon was using this in 1984. So you're right, there is quite a
history.

Re: Confusing ) with } or whatever. The compiler can help a lot. For
example in Mops:

: test { a b -- )
a b + . ;

Error # 245 ')' read when '}' expected
: test { a b -- )
^

Also, if seeing this is a problem then I suspect one is having problems
seeing other characters as well. Either get proper glasses, use a
larger/different font, or get a bigger screen, or any combination of
the above. :-)


Re: FVALUE We have had this in Mops for a long time and I would not
be without it.

Re: Prefix Operators We have also had these in Mops (Neon?) and the
operators are quite smart in that they work on VALUES FVALUES
NamedInputs and Locals. The operators include the equivalents of TO
+TO and -TO ( actually in Mops it's -> "gazinta" ++> and -->, but I'm
not going to quibble).

Re: NamedInputs and Locals re-declared and re-entrance. Egad. The
"We don't need no steenkin' locals" crowd must be gasping. I'm
certainly not anti-locals, but this would seem to be overdoing it. I
gather that you are not proposing this. But I see some discussion
about it. It seems to me that any NamedInputs and locals should be
declared just once up front at the start of the definition. For
clarity at least. Of course if it is allowed I certainly don't have to
use it. :-)

Regards and Good Luck.

-Doug

[Stephen Pelc]

On 23 Aug 2006 17:16:41 -0700, "Doug Hoffman"

Post by Doug Hoffman
Re: FVALUE We have had this in Mops for a long time and I would not
be without it.

I'm just not prepared to write that proposal yet - my flame-proof suit
is scorched enough! Since at least iForth and Mops support it, I
suggest that you or Marcel put a head above the parapet.

Post by Doug Hoffman
Re: Prefix Operators We have also had these in Mops (Neon?) and the
operators are quite smart in that they work on VALUES FVALUES
NamedInputs and Locals. The operators include the equivalents of TO
+TO and -TO ( actually in Mops it's -> "gazinta" ++> and -->, but I'm
not going to quibble).

MPE has had -> ("gazinta") as well since the first implementation.

Stephen

[d***@talkamerica.net]

Post by Stephen Pelc
On 23 Aug 2006 17:16:41 -0700, "Doug Hoffman"

Post by Doug Hoffman
Re: FVALUE We have had this in Mops for a long time and I would not
be without it.

I'm just not prepared to write that proposal yet - my flame-proof suit
is scorched enough!

Understood. Sorry, didn't mean to imply you should take on even more.
You have your hands full as it is!

Post by Stephen Pelc
Since at least iForth and Mops support it, I
suggest that you or Marcel put a head above the parapet.

Marcel would be a good candidate.

Post by Stephen Pelc

Post by Doug Hoffman
Re: Prefix Operators We have also had these in Mops (Neon?) and the
operators are quite smart in that they work on VALUES FVALUES
NamedInputs and Locals. The operators include the equivalents of TO
+TO and -TO ( actually in Mops it's -> "gazinta" ++> and -->, but I'm
not going to quibble).

MPE has had -> ("gazinta") as well since the first implementation.

My apologies to Ward. MacForth has also had FVALUES and the associated
smart gazintas for quite some time (though a slightly different set of
gazintas than Mops).

Regards,

-Doug