RfD: Structures
Peter Knaggs
===============
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
HighJump
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
Peter Knaggs
wrote:
>
> What's up with FILED? Shouldn't it be FIELD?
Yes it should, the file has been updated, but I don't see a need to repost
the whole thing.
--
Peter Knaggs
Anton Ertl
>RfD: Structures
>===============
>
>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:
>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.
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/
Jerry Avins
...
>
> 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)
������������������������������������������������������������������������
Peter Knaggs
<an...@mips.complang.tuwien.ac.at> wrote:
>
> 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.
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
Anton Ertl
>On Wed, 10 Mar 2010 17:23:03 -0000, Anton Ertl
><an...@mips.complang.tuwien.ac.at> wrote:
>>
>> 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.
>
>I feel that the text "after allocating space for an *aligned cell* in the
>current data structure" adequately handles that.
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.
Bruce McFarling
> 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.
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.
Sieur de Bienville
why BEGIN-STRUCTURE, END-STRUCTURE, and the xFIELD: words were
included in the 200x standard since they are all ridiculously trivial
to implement in Standard Forth if +FIELD is available. I tried reading
the rational, but all I got from that was that some people like to
define structures name first and dislike typing in the alignment
words. Would someone explain it a bit more clearly?
Bruce McFarling
wrote:
> On a tangental note, as a newcomer to Forth, I'm not sure I understand
> why BEGIN-STRUCTURE, END-STRUCTURE, and the xFIELD: words were
> included in the 200x standard since they are all ridiculously trivial
> to implement in Standard Forth if +FIELD is available.
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.
Sieur de Bienville
Ed
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.
Peter Knaggs
wrote:
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
Anton Ertl
>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.
Ok.
> name Execution: ( addr1 -- a-addr2 )
> Add an offset to addr1 giving the cell aligned address a-addr2.
Still has the old problems.
Peter Knaggs
<an...@mips.complang.tuwien.ac.at> wrote:
> "Peter Knaggs" <p...@bcs.org.uk> writes:
>> How about:
>> 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
Anton Ertl
>On Tue, 16 Mar 2010 11:02:30 -0000, Anton Ertl
><an...@mips.complang.tuwien.ac.at> wrote:
>> "Peter Knaggs" <p...@bcs.org.uk> writes:
>>> How about:
>>> 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.
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.
Peter Knaggs
> "Peter Knaggs" <p...@bcs.org.uk> writes:
>>
>> So what about this:
>> Add the offset calculated during the compile time action of "FIELD:"
>> to addr1 giving the cell aligned address a-addr2.
>
> 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 ).
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
Anton Ertl
>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.
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.
Bruce McFarling
> name Execution: ( addr1 -- a-addr2 )
> Add an offset to addr1 giving the cell aligned address a-addr2.
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.