Stephen Pelc wrote:
> 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.
> 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).
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.
> 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.
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.
> 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.
know.
> 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.
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.]
> 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.
gives parsing & colouring editors indigestion. 0xA6 is outside the
range of ASCII.
[snipped]
> 0 0 0 0 BUILDLV
Is 0 0 (LOCALS) an equivalent?
--
Regards
Alex McDonald
