stephenXXX@[EMAIL PROTECTED]
(Stephen Pelc) writes:
>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.
>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.
>Standardisation of operators with (for example) floats needs to
>be done before the local types extension can be incor****ated 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.
> 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.
>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
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.
>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.
>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?
>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.
>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:".
>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.
>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".
>Ambiguous conditions:
> 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.
> 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 )".
>
>
>13.6.2.yyyy BUILDLV
This word is used rarely, so we can afford a longer, less cryptic
name. How about BUILD-LOCAL?
>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
>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
"1 cells" instead of "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
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.
>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 im****tant 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.
>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
--
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 2006: http://www.complang.tuwien.ac.at/anton/euroforth2006/
|
