stephenXXX@[EMAIL PROTECTED]
(Stephen Pelc) writes:
>I've had another go at structures, making the assumption that the
>"name-first" and "name-last" camps can't agree and must coexist
>somehow.
I am in the name-last camp, but even though that offers the advantage
of extensibility, this is not such a big issue that I could not live
with a name-first-only proposal. Of course, since you do name-last
for free, that's also ok.
>The proposal text below does not require FIELD to align any
>item. This is deliberate, and allows the construction of groups of
>bytes.
You can do arbitrarily aligned bytes even in a system that sup****ts
alignment, like this:
struct
cell% field foo
char% field bar
byte% 5 * field flip \ <-- group of bytes
float% field flop
....
>Because the current size of the structure is available on
>the top of the stack, words such as ALIGNED (6.1.0706) can be used.
But will they be used? Chances are that many users will try to write the
equivalent of the above like this:
0
1 cells field foo
1 chars field bar \ if they use chars at all
5 field flip \ assuming au=byte
1 floats field flop \ misaligned!
....
As a consequence, accesses to FLOP will be non-standard; they will be
slow on many machines (without the programmer noticing the reason for
the slowness), and fail on others.
>Proposal
>========
>10.6.2.aaaa FIELD
>field FACILITY EXT
>
>( struct-sys n1 n2 "<spaces>name" -- struct-sys n3 )
Unfortunately, this has a conflict with Gforth, which has a word FIELD
with the stack effect ( n1 n2 n3 n4 -- n5 n6 ). Please choose a
different name (but not X_FIELD:-). Does FIELD: have a conflict?
>Return struct-sys unchanged
No need to mention struct-sys in the stack effect, then, and no need
for this sentence. Stuff deeper in the stack than covered by the
stack effect is never changed.
Actually, your requirement for struct-sys would prevent the name-last
use of FIELD that you outlined.
>10.6.2.cccc BEGIN-STRUCTURE
>struct FACILITY EXT
>
>( "<spaces>name" -- struct-sys 0 )
>Skip leading space delimiters. Parse name delimited by a space.
>Create a definition for name with the execution semantics defined
>below. Return an aligned address that will be used by END-STRUCTURE
^^^^^^^^^^^^^^^ struct-sys
>(10.6.2.dddd) and an initial offset of 0.
>
>name Execution: ( -- +n )
>+n is the size in memory expressed in adress units of the data
>structure.
I see a timing problem here: This creates name with its execution
semantics right at the start, but how does name know at the start how
big the structure is going to be? You probably should write that
executing name before its struct-sys was processed by an END-STRUCTURE
to be ambiguous (or something like this).
>10.6.2.eeee CFIELD
....
IMO these don't save enough typing to be worth having in the standard,
especially since you don't even include the alignment.
>10.6.2.ffff IFIELD
>i-field FACILITY EXT
>The execution semantics of IFIELD are identical to the execution
>semantics of the phrase
> 1 CELLS FIELD
If we have this, it should at least be equivalent to
ALIGNED 1 CELLS FIELD
and likewise for FFIELD etc.
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/
|
