access to headers again 
Author Message
 access to headers again

Links to the previous discussions:

http://www.*-*-*.com/

http://www.*-*-*.com/

http://www.*-*-*.com/ %40vir...

----

The header access word set

The bare minimum

Quote:
>HEAD ( xt -- h-id )

HEAD> ( h-id -- xt )
H>#NAME ( h-id -- addr len )
HFLAGS! ( x h-id -- )

        NB: the meaning of bits other than &IMMEDIATE and &HIDDEN
        is system-defined (e.g. name length & one reserved bit).
&IMMEDIATE ( -- x ) single bit
&HIDDEN ( -- x ) single bit; this name is reserved for this use
H>NEXT>H ( h-id -- h-id' ) h-id' describes
          the next-in-chain word list header. When h-id identified
          the last-in-chain header, h-id' is zero.
          There is no guarantee that all word list entries
          belong to a single chain.

[
Two other common use words
HIDE ( -- )
REVEAL ( -- )
really do not belong to the header access group.
]

Extensions (are they really needed?/are implementors ready
to provide them?):

Quote:
>HEADERS ( xt -- h-id1 ... h-idN N ) all hearders for xt  from all word lists
>TCODE ( xt -- tca )            given xt of a : definition, return the

                                address of the corresponding threaded
                                code fragment.

Example of use:
: zz ." hi!";
: z ['] zz >TCODE >RR ;
\ >RR ( tc-addr -- ) ( r: -- tc-addr-r )
z hi! ok

----------------

Below I provide some code. What I want to say with that code?

1. The proposed words may serve as a portable wrapper over
existing systems.
2. The proposed names do not conflict with anyone else's use.
3. The proposed names provide a degree of access to system internals.

These words are a user-reusable implementor's tool.

----------------

Why not just "immed?" and "hidden?" ?

----------------

\ ==== implementation for MPE ProForth VFX ====
\ h-id == nfa

: >HEAD >NAME ; ( xt -- h-id )
: HEAD> NAME> ; ( h-id -- xt )

: H>#NAME COUNT ; ( h-id -- addr len )
8 CONSTANT &HIDDEN ( -- mask )
4 CONSTANT &IMMEDIATE ( -- mask )

: HFLAGS! NFA>CTRL C! ; ( flags h-id -- )
: >TCODE ; ( xt -- tcode-addr )

\ >RR is the same as >R

\ ==== implementation for Win32Forth ====
\ h-id == nfa

: >HEAD >NAME ; ( xt -- h-id )
: HEAD> NAME> ; ( h-id -- xt )


\ $00 CONSTANT &HIDDEN ( -- mask )
$80 CONSTANT &IMMEDIATE ( -- mask )

: HFLAGS! C! ; ( flags h-id -- )
: >TCODE >BODY ; ( xt -- tcode-addr )

\ : >RR POSTPONE REL>ABS POSTPONE >R ; IMMEDIATE

\ ==== implementation for SwiftForth ====
\ h-id == lfa

\ >LINK don't work somewhy
: >HEAD >NAME N>LINK ; ( xt -- h-id )
: HEAD> LINK> ; ( h-id -- xt )

: H>#NAME L>NAME COUNT ; ( h-id -- addr len )
$80 CONSTANT &HIDDEN ( -- mask )
$40 CONSTANT &IMMEDIATE ( -- mask )

: HFLAGS! 1- C! ; ( flags h-id -- )
: >TCODE >CODE ; ( xt -- tcode-addr )

\ : >RR POSTPONE >R ; IMMEDIATE

---
the fewer the navorots, the fewer the glitches
(navorot = unnecessary complication)



Fri, 12 Mar 2004 15:50:00 GMT  
 access to headers again

Quote:

> Below I provide some code. What I want to say with that code?

> 1. The proposed words may serve as a portable wrapper over
> existing systems.
> 2. The proposed names do not conflict with anyone else's use.
> 3. The proposed names provide a degree of access to system internals.

4. The code also shows that although the implementation methods
are very different, a common protocol still can exist.

Quote:
> These words are a user-reusable implementor's tool.
> ----------------

[...]

[...]

[...]


[...]

---
the fewer the navorots, the fewer the glitches
(navorot = unnecessary complication)



Fri, 12 Mar 2004 16:08:41 GMT  
 access to headers again

a) I do not see a need to declare ">HEAD" and "HEAD>" as long
   as ">NAME" and "NAME>" would do the same. This assumes that
   the name-string, the flags and the corresponding XT can be
   derived from an opaque name-token instead of yet another
   thing called head-token. IMHO, this is true for existing
   systems.
b) It is right to declare FLAGS fetch and store words, however
   you also declare bits for hidden and immediate by name but
   in all systems that I have seen *and* which use singlebits
   for this characteristics - all these systems used the
   traditional bitpositions for it, 0x40 and 0x20.
c) NEXT-NAME (as I would call it) does not rightfully belong
   into a declaration-header wordset - it belongs into a set
   of words that can walk a complete wordlist. The name for
   such a word should be made according to the logical scheme
   imposed by a wordlist-walker wordset.
d) NAME>STRING feels okay with a)

as a sum, I would only see to define 3 words to extend the
current common practice to come up with a portable header

For these three, I see a valid use in some applications that
want to examine a definition (esp. an xt being the `behaviour`
of a 'defer'). A valid example would be a highlevel implementation
of a word like 'alias'

I would not like to see too many words being put into the
base system unless there is a valid usage example - please
provide one for 'next-name' if you feel such a word is needed.

that's in short what I see that makes me (and possibly
others) hesitate to adopt any extra header words stuff
above the ones I already have.
cheers, guido                            <standard disclaimer>

Quote:

> The header access word set

> The bare minimum

> >HEAD ( xt -- h-id )
> HEAD> ( h-id -- xt )
> H>#NAME ( h-id -- addr len )
> HFLAGS! ( x h-id -- )

>         NB: the meaning of bits other than &IMMEDIATE and &HIDDEN
>         is system-defined (e.g. name length & one reserved bit).
> &IMMEDIATE ( -- x ) single bit
> &HIDDEN ( -- x ) single bit; this name is reserved for this use
> H>NEXT>H ( h-id -- h-id' ) h-id' describes
>           the next-in-chain word list header. When h-id identified
>           the last-in-chain header, h-id' is zero.
>           There is no guarantee that all word list entries
>           belong to a single chain.

> [
> Two other common use words
> HIDE ( -- )
> REVEAL ( -- )
> really do not belong to the header access group.
> ]

> Extensions (are they really needed?/are implementors ready
> to provide them?):

> >HEADERS ( xt -- h-id1 ... h-idN N ) all hearders for xt  from all word lists

> >TCODE ( xt -- tca )            given xt of a : definition, return the
>                                 address of the corresponding threaded
>                                 code fragment.

> Example of use:
> : zz ." hi!";
> : z ['] zz >TCODE >RR ;
> \ >RR ( tc-addr -- ) ( r: -- tc-addr-r )
> z hi! ok

> ----------------

> Below I provide some code. What I want to say with that code?

> 1. The proposed words may serve as a portable wrapper over
> existing systems.
> 2. The proposed names do not conflict with anyone else's use.
> 3. The proposed names provide a degree of access to system internals.

> These words are a user-reusable implementor's tool.

> ----------------

> Why not just "immed?" and "hidden?" ?

> ----------------

> \ ==== implementation for MPE ProForth VFX ====
> \ h-id == nfa

> : >HEAD >NAME ; ( xt -- h-id )
> : HEAD> NAME> ; ( h-id -- xt )

> : H>#NAME COUNT ; ( h-id -- addr len )
> 8 CONSTANT &HIDDEN ( -- mask )
> 4 CONSTANT &IMMEDIATE ( -- mask )

> : HFLAGS! NFA>CTRL C! ; ( flags h-id -- )
> : >TCODE ; ( xt -- tcode-addr )

> \ >RR is the same as >R

> \ ==== implementation for Win32Forth ====
> \ h-id == nfa

> : >HEAD >NAME ; ( xt -- h-id )
> : HEAD> NAME> ; ( h-id -- xt )


> \ $00 CONSTANT &HIDDEN ( -- mask )
> $80 CONSTANT &IMMEDIATE ( -- mask )

> : HFLAGS! C! ; ( flags h-id -- )
> : >TCODE >BODY ; ( xt -- tcode-addr )

> \ : >RR POSTPONE REL>ABS POSTPONE >R ; IMMEDIATE

> \ ==== implementation for SwiftForth ====
> \ h-id == lfa

> \ >LINK don't work somewhy
> : >HEAD >NAME N>LINK ; ( xt -- h-id )
> : HEAD> LINK> ; ( h-id -- xt )

> : H>#NAME L>NAME COUNT ; ( h-id -- addr len )
> $80 CONSTANT &HIDDEN ( -- mask )
> $40 CONSTANT &IMMEDIATE ( -- mask )

> : HFLAGS! 1- C! ; ( flags h-id -- )
> : >TCODE >CODE ; ( xt -- tcode-addr )

> \ : >RR POSTPONE >R ; IMMEDIATE

> ---
> the fewer the navorots, the fewer the glitches
> (navorot = unnecessary complication)



Fri, 12 Mar 2004 20:45:51 GMT  
 access to headers again

Quote:

> a) I do not see a need to declare ">HEAD" and "HEAD>" as long
>    as ">NAME" and "NAME>" would do the same. This assumes that
>    the name-string, the flags and the corresponding XT can be
>    derived from an opaque name-token instead of yet another
>    thing called head-token. IMHO, this is true for existing
>    systems.

Ok, let us see what is going on.
Although in Forth-83 >NAME was defined as ( cfa -- nfa ),
we *redefine* it as ( xt -- name-token ), where name-token
may be either NFA or LFA or whatever else. We get two versions
of >NAME in common practice, with similar but different meanings.
There is much existing code of the sort >NAME COUNT TYPE ,
and that code gets broken. Those whose code gets broken disagree
with the specification. They say that >NAME is unstandard
and is a wordlist entry stepper from Forth-83, that it always
returned NFA and that they do not want to hear about any name
tokens [they make some impolite gesture], and that they have no
time to chase any specification that can appear in comp.lang.forth .
The goal is not reached.

So let us leave >NAME alone and let it mean what it already means.
The ANSI TC did not redefine COMPILE but invented POSTPONE instead.
At least, the existing code was not broken and the POSTPONE problems
have never been COMPILE problems.

Quote:
> b) It is right to declare FLAGS fetch and store words, however
>    you also declare bits for hidden and immediate by name but
>    in all systems that I have seen *and* which use singlebits
>    for this characteristics - all these systems used the
>    traditional bitpositions for it, 0x40 and 0x20.


\ ==== implementation for MPE ProForth VFX ====
[...]
8 CONSTANT &HIDDEN ( -- mask )
4 CONSTANT &IMMEDIATE ( -- mask )
[...]

\ ==== implementation for Win32Forth ====
[...]
\ $00 CONSTANT &HIDDEN ( -- mask )
$80 CONSTANT &IMMEDIATE ( -- mask )
[...]

\ ==== implementation for SwiftForth ====
[...]
$80 CONSTANT &HIDDEN ( -- mask )
$40 CONSTANT &IMMEDIATE ( -- mask )
[...]

BTW, none of the mentioned systems uses 0x40 and 0x20 you refer to.

Quote:
> c) NEXT-NAME (as I would call it) does not rightfully belong
>    into a declaration-header wordset - it belongs into a set
>    of words that can walk a complete wordlist. The name for
>    such a word should be made according to the logical scheme
>    imposed by a wordlist-walker wordset.

Yes, that ( H>NEXT>H ) alone indeed is not enough.
But I use it more often that other whole-wordlist access words.
Mostly with $10 - $20 DUMP .

Quote:
> d) NAME>STRING feels okay with a)

[arguments against a) are given above]

Quote:
>[...]

> I would not like to see too many words being put into the
> base system unless there is a valid usage example - please
> provide one for 'next-name' if you feel such a word is needed.

1) given an address, find name in whose data field/threaded code it is.

2) given a string (seq of chars), report all words whose names
include that string

3) find all names for a given xt

But again, H>NEXT>H is

Quote:
> > a user-reusable implementor's tool.

So the approach is a bit different from the TC's one.
Quote:

> that's in short what I see that makes me (and possibly
> others) hesitate to adopt any extra header words stuff
> above the ones I already have.
> cheers, guido                            <standard disclaimer>


> > The header access word set

> > The bare minimum

> > >HEAD ( xt -- h-id )
> > HEAD> ( h-id -- xt )
> > H>#NAME ( h-id -- addr len )
> > HFLAGS! ( x h-id -- )

> >         NB: the meaning of bits other than &IMMEDIATE and &HIDDEN
> >         is system-defined (e.g. name length & one reserved bit).
> > &IMMEDIATE ( -- x ) single bit
> > &HIDDEN ( -- x ) single bit; this name is reserved for this use
> > H>NEXT>H ( h-id -- h-id' ) h-id' describes
> >           the next-in-chain word list header. When h-id identified
> >           the last-in-chain header, h-id' is zero.
> >           There is no guarantee that all word list entries
> >           belong to a single chain.

> > [
> > Two other common use words
> > HIDE ( -- )
> > REVEAL ( -- )
> > really do not belong to the header access group.
> > ]

> > Extensions (are they really needed?/are implementors ready
> > to provide them?):

> > >HEADERS ( xt -- h-id1 ... h-idN N ) all hearders for xt  from all word lists

> > >TCODE ( xt -- tca )            given xt of a : definition, return the
> >                                 address of the corresponding threaded
> >                                 code fragment.

> > Example of use:
> > : zz ." hi!";
> > : z ['] zz >TCODE >RR ;
> > \ >RR ( tc-addr -- ) ( r: -- tc-addr-r )
> > z hi! ok

> > ----------------

> > Below I provide some code. What I want to say with that code?

> > 1. The proposed words may serve as a portable wrapper over
> > existing systems.
> > 2. The proposed names do not conflict with anyone else's use.
> > 3. The proposed names provide a degree of access to system internals.

> > These words are a user-reusable implementor's tool.

> > ----------------

> > Why not just "immed?" and "hidden?" ?

> > ----------------

> > \ ==== implementation for MPE ProForth VFX ====
> > \ h-id == nfa

> > : >HEAD >NAME ; ( xt -- h-id )
> > : HEAD> NAME> ; ( h-id -- xt )

> > : H>#NAME COUNT ; ( h-id -- addr len )
> > 8 CONSTANT &HIDDEN ( -- mask )
> > 4 CONSTANT &IMMEDIATE ( -- mask )

> > : HFLAGS! NFA>CTRL C! ; ( flags h-id -- )
> > : >TCODE ; ( xt -- tcode-addr )

> > \ >RR is the same as >R

> > \ ==== implementation for Win32Forth ====
> > \ h-id == nfa

> > : >HEAD >NAME ; ( xt -- h-id )
> > : HEAD> NAME> ; ( h-id -- xt )


> > \ $00 CONSTANT &HIDDEN ( -- mask )
> > $80 CONSTANT &IMMEDIATE ( -- mask )

> > : HFLAGS! C! ; ( flags h-id -- )
> > : >TCODE >BODY ; ( xt -- tcode-addr )

> > \ : >RR POSTPONE REL>ABS POSTPONE >R ; IMMEDIATE

> > \ ==== implementation for SwiftForth ====
> > \ h-id == lfa

> > \ >LINK don't work somewhy
> > : >HEAD >NAME N>LINK ; ( xt -- h-id )
> > : HEAD> LINK> ; ( h-id -- xt )

> > : H>#NAME L>NAME COUNT ; ( h-id -- addr len )
> > $80 CONSTANT &HIDDEN ( -- mask )
> > $40 CONSTANT &IMMEDIATE ( -- mask )

> > : HFLAGS! 1- C! ; ( flags h-id -- )
> > : >TCODE >CODE ; ( xt -- tcode-addr )

> > \ : >RR POSTPONE >R ; IMMEDIATE

> > ---
> > the fewer the navorots, the fewer the glitches
> > (navorot = unnecessary complication)



Sat, 13 Mar 2004 15:25:55 GMT  
 access to headers again
On Tue, 25 Sep 2001 11:25:55 +0400, "Michael L.Gassanenko"

Quote:


>> a) I do not see a need to declare ">HEAD" and "HEAD>" as long
>>    as ">NAME" and "NAME>" would do the same. This assumes that
>>    the name-string, the flags and the corresponding XT can be
>>    derived from an opaque name-token instead of yet another
>>    thing called head-token. IMHO, this is true for existing
>>    systems.
>Ok, let us see what is going on.
>Although in Forth-83 >NAME was defined as ( cfa -- nfa ),
>we *redefine* it as ( xt -- name-token ), where name-token
>may be either NFA or LFA or whatever else. We get two versions
>of >NAME in common practice, with similar but different meanings.
>There is much existing code of the sort >NAME COUNT TYPE ,
>and that code gets broken.

Wouldn't code like >NAME COUNT TYPE be broken anyway on a system where
you don't have a NFA pointing to a counted string?

But anyway, the argument would be that it is better on such a system
for it to{*filter*}at

? >NAME

instead of gagging at TYPING something that is not a counted string
after all.

An XT could be a CFA, it could be related to a CFA, and there might
not be a CFA ... instead of a code field it might be an offset to the
interpretation machine code with the compilation machine code
following immediate after the name.

Which is the reason for names like XT>NAME and NAME>STRING.  If the XT
is the CFA, and NAME>STRING is just COUNT, you've got it in two

: XT>NAME ( xt -- name-id ) >NAME ;
: NAME>STRING ( name-id -- ca u ) COUNT ;

and where its more complicated, maybe its not THAT much more
complicated:

31 CONSTANT NAME-LEN-MASK
: XT>NAME ( xt -- name-id ) >NAME ;
: NAME>STRING ( name-id -- ca u ) COUNT NAME-LEN-MASK AND ;

Quote:
>Those whose code gets broken disagree
>with the specification. They say that >NAME is unstandard
>and is a wordlist entry stepper from Forth-83, that it always
>returned NFA and that they do not want to hear about any name
>tokens [they make some impolite gesture], and that they have no
>time to chase any specification that can appear in comp.lang.forth .
>The goal is not reached.
>So let us leave >NAME alone and let it mean what it already means.
>The ANSI TC did not redefine COMPILE but invented POSTPONE instead.
>At least, the existing code was not broken and the POSTPONE problems
>have never been COMPILE problems.

So I strongly agree.

(
----------
Virtually,

Bruce McFarling, Newcastle,

)



Sat, 13 Mar 2004 16:39:23 GMT  
 access to headers again


Quote:
>b) It is right to declare FLAGS fetch and store words, however
>   you also declare bits for hidden and immediate by name but
>   in all systems that I have seen *and* which use singlebits
>   for this characteristics - all these systems used the
>   traditional bitpositions for it, 0x40 and 0x20.

Gforth in the current development kernel on a 64-bit machine:

alias-mask hex. $8000000000000000  ok
immediate-mask hex. $4000000000000000  ok
restrict-mask hex.  $2000000000000000 ok

Quote:
>c) NEXT-NAME (as I would call it) does not rightfully belong
>   into a declaration-header wordset - it belongs into a set
>   of words that can walk a complete wordlist. The name for
>   such a word should be made according to the logical scheme
>   imposed by a wordlist-walker wordset.

The name you propose can easily be mixed up with

|`nextname'       c-addr u -         gforth       ``nextname''
|   The next defined word will have the name C-ADDR U; the defining word
|will leave the input stream alone.
|
|   For example:
|
|     s" foo" nextname create
|
|is equivalent to:
|
|     create foo
|
|`nextname' works with any defining word.

- 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



Sat, 13 Mar 2004 21:08:29 GMT  
 access to headers again


Quote:

>> a) I do not see a need to declare ">HEAD" and "HEAD>" as long
>>    as ">NAME" and "NAME>" would do the same. This assumes that
>>    the name-string, the flags and the corresponding XT can be
>>    derived from an opaque name-token instead of yet another
>>    thing called head-token. IMHO, this is true for existing
>>    systems.

>Ok, let us see what is going on.
>Although in Forth-83 >NAME was defined as ( cfa -- nfa ),
>we *redefine* it as ( xt -- name-token ), where name-token
>may be either NFA or LFA or whatever else. We get two versions
>of >NAME in common practice, with similar but different meanings.
>There is much existing code of the sort >NAME COUNT TYPE ,
>and that code gets broken.

That will fail on many systems anyway, because the top three bits are
used for flags.  >NAME COUNT 31 AND TYPE may be more common.

However, this has never worked on Gforth (where the link field
precedes the name field, and the name token points to the link field),
but I don't remember any questions or complaints about this, so maybe
such code is not as frequent as you think.

The Gforth developers have discussed >NAME vs. >HEAD in 1997, and the
differences between Gforth and F83 are these:

F83 has a 1:1 relationship between head and xt, Gforth has an m:n
relationship (aliases and nonames cause m>=0 heads, combined words
have 2 xts).  This means that F83 can treat the word as one structure,
whereas Gforth has to treat heads and bodies as separate structures.

F83 has words for getting from one field to the next, whereas Gforth
has words that take the the start of the respective structure (as name
token or execution token), and access the various fields (e.g.,
NAME>STRING or >BODY) and get to the other structure (e.g., >NAME and
NAME>INT), if possible.

After discussing this for a while nobody was against renaming all the
NAME words into using HEAD instead, but in the end nobody performed
this renaming:-) There is an alias >HEAD for >NAME, but all the other
aliases are missing.

Since no problems with the NAME words have been reported, I guess it's
not that important.

- 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



Sat, 13 Mar 2004 21:46:18 GMT  
 access to headers again

Quote:

> After discussing this for a while nobody was against renaming all the
> NAME words into using HEAD instead, but in the end nobody performed
> this renaming:-) There is an alias >HEAD for >NAME, but all the other
> aliases are missing.

The current proposal is to assign a *slightly different*
semantics to HEAD words. It is good that the proposed names
(HEAD words) have not been used before.

Quote:
> Since no problems with the NAME words have been reported, I guess it's
> not that important.

This equally may mean that everybody understands that existing Forth systems are not compatible at the level of NAME words.

Or that those whose applications needed access to the headers
did not use gForth.

Or this may mean something else...

I underline once again,
the HEAD words are user-reusable implementor's words.

--
do not do that -- universal advice

( I mean, "may be given" <> "can be followed")



Sat, 13 Mar 2004 22:31:27 GMT  
 access to headers again

Quote:


> > After discussing this for a while nobody was against renaming all the
> > NAME words into using HEAD instead, but in the end nobody performed
> > this renaming:-) There is an alias >HEAD for >NAME, but all the other
> > aliases are missing.

> The current proposal is to assign a *slightly different*
> semantics to HEAD words. It is good that the proposed names
> (HEAD words) have not been used before.

> > Since no problems with the NAME words have been reported, I guess it's
> > not that important.

> This equally may mean that everybody understands that existing Forth systems are not compatible at the level of NAME words.

> Or that those whose applications needed access to the headers
> did not use gForth.

> Or this may mean something else...

> I underline once again,
> the HEAD words are user-reusable implementor's words.

They'll only get implemented if they have a real benefit over the old
style. The original reference in fst83 annex did not specify anything
about the result of ">name" is supposed to look like - just that it is
a pointer to someting called a name-field but there is no restriction
on the layout of what that is. Any assumption here is non-portable even
from the original specs - you can only speak from the point of "common
practice" which there isn't AFAICS - the fig-like ones would use the
"common practice" to `count 31 and` while later many forth systems have
relaxed to just doing `count` and even other might have used a zero-
terminated string-reference somewhere else. That's why I strongly
recommend to adopt words that can finally *do something* and *portably*
with the returned value of `>name` - no hints about possible
operations were specified in the original fst83 section and no portable
program did assume anything since there *are* actually different styles
of deriving the namestring or flags from the `>name`-returnvalue. Even
pfe can not be safely assumed to do just `count` since the header-layout
can be configure to fig-style - a pfe program may not assume a certain
header style even when detecting a pfe environment - imagine that. And
likewise I assume that many forth system have undergone some evolution
in the past with changes in the header-layout - so you can not assume
a certain header-style by just checking for `gforth` or any other forth
implementation out there - and these differences in header-style even
affect what `>name` does return. One can only come forward with making
operations that adapt to the local constitution of headers. Now just
again - what's the difference between finally making operations that
work on top of `>head` or just some that will work on `>name`???????
And again - there is no `portable practice` in deriving either fields
or the stringspan from the `>name`-returnvalue. Show me if you think
otherwise.

cheers,
-- guido                            Edel sei der Mensch, hilfreich und gut



Sat, 13 Mar 2004 23:30:56 GMT  
 access to headers again

Quote:

> > b) It is right to declare FLAGS fetch and store words, however
> >    you also declare bits for hidden and immediate by name but
> >    in all systems that I have seen *and* which use singlebits
> >    for this characteristics - all these systems used the
> >    traditional bitpositions for it, 0x40 and 0x20.


> \ ==== implementation for MPE ProForth VFX ====
> [...]
> 8 CONSTANT &HIDDEN ( -- mask )
> 4 CONSTANT &IMMEDIATE ( -- mask )
> [...]

> \ ==== implementation for Win32Forth ====
> [...]
> \ $00 CONSTANT &HIDDEN ( -- mask )
> $80 CONSTANT &IMMEDIATE ( -- mask )
> [...]

> \ ==== implementation for SwiftForth ====
> [...]
> $80 CONSTANT &HIDDEN ( -- mask )
> $40 CONSTANT &IMMEDIATE ( -- mask )
> [...]

> BTW, none of the mentioned systems uses 0x40 and 0x20 you refer to.

I was aware that the notion of `smudge`d words are implemented quite
differently and often far from using a bit for it (e.g. a new colonword
gets registered in `last` but it is not chained into the `current`
wordlist until the final semicolon). However I am suprised to see so
many implementations dump 0x40 for the immediate bit as I do know
quite some forth sources that do check with that for just this bit.
I am not aware what benefit that had to just use fewer bits in the
name-count-byte and dumping immediate-assumption over just assigning
another byte in front and adding an '>ffa' that could be a noop (and
have an `[undefined] >ffa [if] : >ffa noop ; [then] in app sources
that want to be a bit more portable).

anyway, I have to dump this argument then,
well then,
-- guido                            Edel sei der Mensch, hilfreich und gut



Sat, 13 Mar 2004 23:42:32 GMT  
 access to headers again

Quote:

> >[...]

> > I would not like to see too many words being put into the
> > base system unless there is a valid usage example - please
> > provide one for 'next-name' if you feel such a word is needed.

> 1) given an address, find name in whose data field/threaded code it is.

??? name-segment and data-segment could be totally off, right?

Quote:

> 2) given a string (seq of chars), report all words whose names
> include that string

what? I have hashed wordlists (quite common these days), and
going along one chain of words does not present all words that
could possibly contain a seq-of-chars.

Quote:

> 3) find all names for a given xt

> But again, H>NEXT>H is
> > > a user-reusable implementor's tool.
> So the approach is a bit different from the TC's one.

Again, how do you define such without a word that jumps from
one wordlist-bucket to the next? And most importantly a
word that gives you the first wordlist-bucket or atleast the
first name in that wordlist? `latest` does certainly not
count, right?

I counle see a good "next-name" definition if it is defined
amongst other words that define a `first-word-of-wordlist`.
But it would not work with a single-item for a header-token
in my system as the last word in a chain down from a
bucket does not know about the next bucket or which wordlist
it is in. 'next-name' is okay if there are other words that
can take a wordlist and iterate over each start of a
header-chain and where the chain-items can then be examined
one after the other with a `next-name` operation.

cheers,
-- guido                            Edel sei der Mensch, hilfreich und gut



Sat, 13 Mar 2004 23:51:54 GMT  
 access to headers again

Quote:

> >c) NEXT-NAME (as I would call it) does not rightfully belong
> >   into a declaration-header wordset - it belongs into a set
> >   of words that can walk a complete wordlist. The name for
> >   such a word should be made according to the logical scheme
> >   imposed by a wordlist-walker wordset.

> The name you propose can easily be mixed up with

> |`nextname'       c-addr u -         gforth       ``nextname''
> |   The next defined word will have the name C-ADDR U; the defining word
> |will leave the input stream alone.
> |
> |   For example:
> |
> |     s" foo" nextname create
> |
> |is equivalent to:
> |
> |     create foo
> |
> |`nextname' works with any defining word.

yeah, I've seen gforth using "name" for a parsing-thing but I am not
that aware what was wrong with 'parse-next' or 'next-word' that we see
sometimes around. The term 'name' is a bit general and from just
reading gforth soures I would not expect it to go parsing but I would
if it had contained the particle 'parse' or 'word'. Are there many
other systems that use "name"? I dunno but gforth is certainly a
widely-used system so one should take care to what it would be called.

right then,
cheers,
-- guido                            Edel sei der Mensch, hilfreich und gut



Sat, 13 Mar 2004 23:57:37 GMT  
 access to headers again


Quote:
>yeah, I've seen gforth using "name" for a parsing-thing but I am not
>that aware what was wrong with 'parse-next' or 'next-word' that we see
>sometimes around.

PARSE-WORD.  The only thing that's wrong is that it was used with a
different meaning (that word is now called SWORD) in an earlier version
of Gforth, so the name needed a few releases of undefinition to cool
off.  I guess we can add PARSE-WORD with the meaning of NAME in the
next release.

But why do you mention that in a discussion of NEXTNAME/NEXT-NAME?

- 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



Sun, 14 Mar 2004 01:07:50 GMT  
 access to headers again

Quote:



> >yeah, I've seen gforth using "name" for a parsing-thing but I am not
> >that aware what was wrong with 'parse-next' or 'next-word' that we see
> >sometimes around.

> PARSE-WORD.  The only thing that's wrong is that it was used with a
> different meaning (that word is now called SWORD) in an earlier version
> of Gforth, so the name needed a few releases of undefinition to cool
> off.  I guess we can add PARSE-WORD with the meaning of NAME in the
> next release.

> But why do you mention that in a discussion of NEXTNAME/NEXT-NAME?

cause it goes with parsingword 'create', and again I wonder about
the use of the particle 'name' in this respect. I would not get
intuitivly the relation to 'create' or other parse/define words
but I came to know that gforth has been building such a relation
in quite some places. In all these places where 'name' was used
I wonder what made it wrong to use the particles 'parse' or 'word'

(in this case may be 'as-next-create-word' which draws a strong
relation to 'create' and a 'pars'ing thing 'next' to come. yeah,
it's a long word...[;-)] ).

anyway, gforth has made quite some usage
of the 'name' particle as we see...
cheers,
-- guido                            Edel sei der Mensch, hilfreich und gut



Sun, 14 Mar 2004 01:54:01 GMT  
 access to headers again

Quote:



> > > After discussing this for a while nobody was against renaming all the
> > > NAME words into using HEAD instead, but in the end nobody performed
> > > this renaming:-) There is an alias >HEAD for >NAME, but all the other
> > > aliases are missing.

> > The current proposal is to assign a *slightly different*
> > semantics to HEAD words. It is good that the proposed names
> > (HEAD words) have not been used before.

> > > Since no problems with the NAME words have been reported, I guess it's
> > > not that important.

> > This equally may mean that everybody understands that existing Forth systems are not compatible at the level of NAME words.

> > Or that those whose applications needed access to the headers
> > did not use gForth.

> > Or this may mean something else...

> > I underline once again,
> > the HEAD words are user-reusable implementor's words.

> They'll only get implemented if they have a real benefit over the old
> style.

Benefit: the implementor's words are portably reusable.
How often this is needed? Sometimes.
Many programming languages survive without any {*filter*}
features like Forth's access to the input source and name spaces.

Quote:
> The original reference in fst83 annex did not specify anything
> about the result of ">name" is supposed to look like - just that it is
> a pointer to someting called a name-field but there is no restriction
> on the layout of what that is. Any assumption here is non-portable even
> from the original specs - you can only speak from the point of "common
> practice" which there isn't AFAICS - the fig-like ones would use the
> "common practice" to `count 31 and` while later many forth systems have
> relaxed to just doing `count` and even other might have used a zero-
> terminated string-reference somewhere else.

The Forth-83 proposal said "name field".
It did not say what the name field is.
But this was not done intentionally.
This was a mistake.

The author assumed the FIG-like model:

Link field contains the address of the next word.
Name field contains [len+flags] "name"
Code field contains something which points to native code
Data field contains parameters, its address is passed to that code

But these assumptions have not been included into the "specification".

This is why >NAME is not in ANS Forth and why we (in c.l.f.) are having
problems with it.

Quote:
> That's why I strongly
> recommend to adopt words that can finally *do something* and *portably*
> with the returned value of `>name`

The name >NAME is *already taken* for *doing something system-specific*
and *non-portable*. Each system already has its own >NAME.
Currently >NAME is a sign of system-dependency.
On some systems the value returned by >NAME may not be suitable
as the header-id. (For example, LFA may be the central thing.)
For such systems, the introduced words will not be usable
at the system implementation level because of the conceptual
mismatch of the existing implementation and the proposed word set
(e.g. lfa-centered design vs. nfa-centered wordset).

Once again: LFA-centered design.
You cannot rename >LINK to >NAME because this would
break everything. But you do not want words that use
NFA where they should use LFA.

Quote:
> - no hints about possible
> operations were specified in the original fst83 section and no portable
> program did assume anything since there *are* actually different styles
> of deriving the namestring or flags from the `>name`-returnvalue. Even
> pfe can not be safely assumed to do just `count` since the header-layout
> can be configure to fig-style - a pfe program may not assume a certain
> header style even when detecting a pfe environment - imagine that. And
> likewise I assume that many forth system have undergone some evolution
> in the past with changes in the header-layout - so you can not assume
> a certain header-style by just checking for `gforth` or any other forth
> implementation out there - and these differences in header-style even
> affect what `>name` does return. One can only come forward with making
> operations that adapt to the local constitution of headers. Now just
> again - what's the difference between finally making operations that
> work on top of `>head` or just some that will work on `>name`???????

If on top of >NAME :
The system implementor has (1) the name-id-centered specification
and (2) his existing system where >NAME very well may return
something not well-suitable as a handle to the word list header.
The system implementor has to put the requirements together.
The chances that the result will be what the implementor
would like to use in his own sytem are 50:50.

If on top of >HEAD :
The system implementor has the header-id-centered specification.
He defines >HEAD as an alias of >NAME or >LINK or whatever
is more convenient. The implementooor maps the new names onto
the entities existing in the system.

So the difference is that the implementor has less problems
in the 2nd case. >NAME already means something; >HEAD may
have a new meaning.

In the nature, when hedgehogs get born, their {*filter*}les are soft.
A Russian saying tells us that it's difficult to give birth to
an [{*filter*}] hedgehog.
The NAME words are an {*filter*} hedgehog.

Quote:
> And again - there is no `portable practice` in deriving either fields
> or the stringspan from the `>name`-returnvalue. Show me if you think
> otherwise.

There is no portable practice, but the common practice is that
each system defined NAME words in its own unique fashion.
You cannot painlessly define NAME words because it will
hurt each system in its own way.


Sun, 14 Mar 2004 15:39:46 GMT  
 
 [ 61 post ]  Go to page: [1] [2] [3] [4] [5]

 Relevant Pages 

1. Newsgroup access again, good to see you all again

2. Scheme vs ML again and again and again and again

3. Scheme vs ML again and again and again and again

4. mime.tcl again - headers this time ;>

5. F90 migration: Win2k and unformatted, direct-access files with headers

6. Access and ODBC (again)

7. TPS Access again

8. Limited Type Access - Again

9. Limited Type Access - Again

10. Access violation after nullifiying and again allocating pointer

11. Family tree access again

12. Unified data access again

 

 
Powered by phpBB® Forum Software