2010-02-24 Drafting of RfD
2009-09-03 Original wordsmithing of solution during 200x meeting.
Problem
=======
The X:structures extension defines FILED: as:
10.6.2.xxxx FILED: "field-colon" FACILITY EXT
( -- ) X:structures
The semantics of FIELD: are identical to the execution semantics
of the phrase:
ALIGNED 1 CELLS +FIELD
See: 10.6.2.0 +FIELD, 10.6.2.0 BEGIN-STRUCTURE and
10.6.2.0 END-STRUCTURE.
While this is a very concise definition, there are a few difficulties
with it:
1) The stack description is incorrect, it should be:
( n1 "<spaces>name" -- n2 )
2) It defines a child word which is not described. Normally this is
described in a "name Execution" clause.
3) There is no actual description of the word, simply what amounts
to a reference implementation.
This applies to CFIELD:, DFFIELD:, FFIELD: and SFFIELD: as well.
Solution
========
Replace the definition of FIELD: and friends with:
10.6.2.---- FILED: "field-colon" FACILITY EXT
( n1 "<spaces>name" -- n2 ) X:structures
Skip leading space delimiters. Parse name delimited by a space.
Create a definition for name with the execution semantics defined
below. n2 is the next available offset from n1 after allocating
space for an aligned cell in the current data structure.
FIELD: creates a single cell field in a data structure. The
execution semantics are identical to:
ALIGNED 1 CELLS +FIELD
name Execution: ( addr1 -- a-addr2 )
Add n1 (cell aligned) to addr1 giving the cell aligned address
a-addr2.
See: 10.6.2.---- +FIELD, 10.6.2.---- BEGIN-STRUCTURE,
10.6.2.---- END-STRUCTURE, A.10.6.---- BEGIN-STRUCTURE.
Proposal
========
Modify the definition of the following words in accordance with the
text given in the Solution, above, with the modification of the
alignment as follows:
FIELD: cell aligned
CFIELD: character aligned
FFIELD: float aligned
SFFIELD: single-float aligned
DFFIELD: double-float aligned
Author
======
Peter Knaggs <p...@bcs.org.uk>
School of Engineering, Mathematics and Physical Sciences,
University of Exeter, Exeter, Devon EX4 7QF, England
--
Peter Knaggs
On Feb 23, 6:01 pm, "Peter Knaggs" <p...@bcs.org.uk> wrote:
> Solution
> ========
>
> Replace the definition of FIELD: and friends with:
>
> 10.6.2.---- FILED: "field-colon" FACILITY EXT
> ( n1 "<spaces>name" -- n2 ) X:structures
>
> Peter Knaggs
Yes it should, the file has been updated, but I don't see a need to repost
the whole thing.
--
Peter Knaggs
Is this really a difficulty? In general, specification by
implementation is a bad idea, for the following reasons:
a) In general an implementation is an overspecification, i.e., it
specifies more than is intended.
b) An implementation is often harder to understand than an English
description.
In the present case, I believe that a) is not the case. And at least
wrt the proposed English definition, b) is also not the case; and I
don't think that an English definition can be written that is clearer
than the code. One might add some words about the purpose of the
word, though (maybe in the Rationale?)..
Here's the proposed English definition:
> 10.6.2.---- FILED: "field-colon" FACILITY EXT
> ( n1 "<spaces>name" -- n2 ) X:structures
>
> Skip leading space delimiters. Parse name delimited by a space.
> Create a definition for name with the execution semantics defined
> below. n2 is the next available offset from n1 after allocating
> space for an aligned cell in the current data structure.
>
> FIELD: creates a single cell field in a data structure. The
> execution semantics are identical to:
>
> ALIGNED 1 CELLS +FIELD
>
> name Execution: ( addr1 -- a-addr2 )
> Add n1 (cell aligned) to addr1 giving the cell aligned address
> a-addr2.
>
> See: 10.6.2.---- +FIELD, 10.6.2.---- BEGIN-STRUCTURE,
> 10.6.2.---- END-STRUCTURE, A.10.6.---- BEGIN-STRUCTURE.
If we want to have an English specification, I think that the English
text does not specify the alignment clearly (in no place where it is
mentioned). Without the Forth code, it would be unclear where to
perform ALIGNED and where not. Also, addr1 should probably be a-addr1
(and for DFFIELD both addresses should be DFALIGNED etc.).
I wonder if the double specification here (in English and in Forth)
might not lead to a problem, if they contradict each other.
- 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 2009: http://www.euroforth.org/ef09/
...
>
> Here's the proposed English definition:
>
>> 10.6.2.---- FILED: "field-colon" FACILITY EXT
FIELD: , not FILED: .
...
Jerry
--
Physics is like sex: sure, it may give some practical results, but
that's not why we do it. -- Richard P. Feynman (Nobel Prize, Physics)
������������������������������������������������������������������������
I feel that the text "after allocating space for an *aligned cell* in the
current data structure" adequately handles that. Although I do think the
Forth equivalence does clarify things.
> Also, addr1 should probably be a-addr1
No, there is no guarantee that addr1 is aligned in any way.
> I wonder if the double specification here (in English and in Forth)
> might not lead to a problem, if they contradict each other.
If there where a contradiction then I would agree, but as there is not, or
at least nobody has identified one, I fell happy that the proposal is
contradiction free.
--
Peter Knaggs
I feel that it is not very clear, especially in conjunction with the
rest.
>> Also, addr1 should probably be a-addr1
>
>No, there is no guarantee that addr1 is aligned in any way.
If addr1 is not aligned, then the result won't be aligned, either (at
least with the original definition; your English definition is less
clear).
An "a-addr1" on the input stack effect does not specify what the
system guarantees, but what it expects from the program. I.e., if you
want to use fields created with FIELD:, better use addresses that are
cell-aligned.
I think that the standard is quite lacking in that area in some
places. Cell alignment is handled ok, but everything else is missing.
CREATE and ALLOCATE should produce addresses that are aligned wrt all
alignment words supported by the system, otherwise CREATE is not
really usable with structures containing anything but cells, and using
ALLOCATE becomes much more cumbersome.
And there should be an alignment word that guarantees such alignment
(Gforth has MAXALIGNED and MAXALIGN).
>> I wonder if the double specification here (in English and in Forth)
>> might not lead to a problem, if they contradict each other.
>
>If there where a contradiction then I would agree, but as there is not, or
>at least nobody has identified one, I fell happy that the proposal is
>contradiction free.
I, Nobody Ertl, find the wording wrt alignment at least unclear, and
possibly even contradicting the Forth code.
If the Forth equivalence clarifies things, then perhaps the phrasing
of the specification suggests rather than specifies.
"n2 is the next available offset from n1, after reserving space for
cell alignment if required, then allocating space for a cell in the
current data structure."
The sequence by reference to existing standard semantics is not
incidental, since aligning *merely* to conform with the English text
and the stack diagram could be done as the final operation, which
would subvert the purpose of having an aligned field definer.
For all of them, its the ability to use the implementation versions if
they exist and only roll your own if they are absent. So for BEGIN-
STRUCTURE / END-STRUCTURE, one part would be so that you can:
[UNDEFINED] BEGIN-STRUCTURE [IF] ...
... in an implementation that respects the standard, and then ensure
that you have the same behavior whether you found it there or defined
it yourself.
One portability trap is when a BEGIN-STRUCTURE / END-STRUCTURE does
not provide the standard behavior, but that it does extra stuff that
the implementation / user finds handy. The other portability trap
would be BEGIN-STRUCTURE and END-STRUCTURE in a name-last approach,
and then your [UNDEFINED] returns false but its not really the same
BEGIN-STRUCTURE after all.
For xFIELD: I expect the main thing is the auto-aligning ... alignment
is a constant portability trap when moving code from an implementation/
hardware without alignment restrictions to one with alignment
restrictions. Its essential to pin down whether or not the field words
align, and when.
Standard Forth is attempting to become as big and as unweildly as
Standard C and Fortran in the hope that it will become just as unpopular.
Your original surmise is correct. Trust your instincts.
How about:
If n1 is not a cell aligned offset, add an additional offset to
align it. n2 is the next available offset after allocating space
for an aligned cell in the current data structure.
name Execution: ( addr1 -- a-addr2 )
Add an offset to addr1 giving the cell aligned address a-addr2.
--
Peter Knaggs
Ok.
> name Execution: ( addr1 -- a-addr2 )
> Add an offset to addr1 giving the cell aligned address a-addr2.
Still has the old problems.
So what about this:
Add the offset calculated during the compile time action of "FIELD:"
to addr1 giving the cell aligned address a-addr2.
Otherwise we are going to have to go into detail about n1 again, which
seams rather pointless to me.
--
Peter Knaggs
As mentioned, the resulting fields do not give aligned addresses when
the input is not aligned (at least as specified now, and implemented
everywhere), so the stack effect should be either ( a-addr1 -- a-addr2
) or ( addr1 -- addr2 ).
And the "cell aligned" in the sentence sounds as if there was an extra
alignment step when the field is executed, which there isn't.
Therefore the "cell aligned" should be left away there.
>Otherwise we are going to have to go into detail about n1 again, which
>seams rather pointless to me.
It would probably be clearer if you introduced a name for this offset
(say, "u3") and then use the name for referring to this offset.
As mentioned, all of that seems to be pointless to me. We have a
concise and unambiguous specification already. Why not just keep it.
Ah, yes ok.
>> Otherwise we are going to have to go into detail about n1 again, which
>> seams rather pointless to me.
>
> It would probably be clearer if you introduced a name for this offset
> (say, "u3") and then use the name for referring to this offset.
This is the only reasonable way around the problem that I can see.
> As mentioned, all of that seems to be pointless to me. We have a
> concise and unambiguous specification already. Why not just keep it.
I find the idea of providing a semantic equivalence as the only form
of definition abhorrent. If we go down that route, we may as well just
have a reference implementation and no standard.
--
Peter Knaggs
In general this has significant drawbacks; from
<2010Mar1...@mips.complang.tuwien.ac.at>
|a) In general an implementation is an overspecification, i.e., it
| specifies more than is intended.
|
|b) An implementation is often harder to understand than an English
| description.
So in general we don't want to do this. However, in this particular
case, the existing specification in Forth code has neither drawback,
so I don't see any advantage from replacing it with a specification in
English.
This is the problem. That stack picture is confusing alignment of the
*offset* at compile time with alignment of the result when the
structure address is converted to the field address.
What Anton is pointing out is that *the specified alignment* happens
*at compile time*.
The alignment at compile time *allows* the assurance that the field
can be used with an aligned structure to give an aligned offset.
So the *execution* stack picture should be ( a-addr1 -- a-addr2 )
Without the alignment that occurs between ( n1 ) and ( n2 ), the
*execution* stack picture with an aligned address input would be:
name Execution: ( a-addr1 -- addr2 )
... and that is what the ALIGNED in the definition is there to
prevent.