Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #45270 > unrolled thread

SYNONYM question

Back to article view | Back to comp.lang.forth

Contents

  SYNONYM question Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-02-03 12:47 +0000
    Re: SYNONYM question Mark Wills <markwills1970@gmail.com> - 2016-02-03 05:36 -0800
      Re: SYNONYM question stephen@mpeforth.com (Stephen Pelc) - 2016-02-03 15:36 +0000
        Re: SYNONYM question Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-02-03 17:26 +0000
          Re: SYNONYM question Bernd Paysan <bernd.paysan@gmx.de> - 2016-02-27 00:07 +0000
          Re: SYNONYM question hughaguilar96@gmail.com - 2016-02-26 18:44 -0800
        Re: SYNONYM question Mark Wills <markwills1970@gmail.com> - 2016-02-04 02:17 -0800
          Re: SYNONYM question Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-02-04 11:32 +0000
            Re: SYNONYM question stephen@mpeforth.com (Stephen Pelc) - 2016-02-04 17:12 +0000
        Re: SYNONYM question hughaguilar96@gmail.com - 2016-02-08 22:03 -0800
          Re: SYNONYM question Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-03 00:09 +0000
            Re: SYNONYM question hughaguilar96@gmail.com - 2016-03-02 22:02 -0800
    Re: SYNONYM question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-03 15:16 +0000
      Re: SYNONYM question Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-02-03 18:26 +0000
        Re: SYNONYM question Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-02-03 20:09 +0000
          Re: SYNONYM question Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-02-03 20:52 +0000
            Re: SYNONYM question "Elizabeth D. Rather" <erather@forth.com> - 2016-02-03 15:59 -1000
            Re: SYNONYM question Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-02-04 11:25 +0000
        Re: SYNONYM question Mark Wills <markwills1970@gmail.com> - 2016-02-04 02:16 -0800
          Re: SYNONYM question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-04 11:18 +0000
        Re: SYNONYM question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-04 10:54 +0000
          Re: SYNONYM question "HAA" <someone@microsoft.com> - 2016-02-04 23:35 +1100
    Re: SYNONYM question Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-02-03 19:48 +0000
      Re: SYNONYM question "HAA" <someone@microsoft.com> - 2016-02-04 11:07 +1100
      Re: SYNONYM question anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-04 11:08 +0000

Page 1 of 2  [1] 2  Next page →

#45270 — SYNONYM question

If we have:

1234 value x
synonym y x

Is this valid Forth?

9876 to y

Relevant bits of the Forth 2012 standard are:

6.2.2295 TO
"An ambiguous condition exists if name was not defined by a word with “TO
name run-time” semantics."

As y is defined by SYNONYM presumably the above is an ambiguous condition.

This seems wrong to me, after all one of the uses of SYNONYM is to 
redefine a word with the same name in a different wordlist and that, 
apparently cannot be done with VALUEs

Incidentally Gforth gives

1234 value x  ok
synonym y x  ok
9876 to y
:3: error: Invalid name argument
9876 to >>>y<<<

Having written the above, I just realised that exactly the same question 
applies to a SYNONYM of a deferred word and using IS on the synonym.

defer p
synonym q p
' some-def is q

Again Gforth rejects this, but does accept
' some-def ' q defer!
which works correctly.

If these uses of SYNONYM are ambiguous conditions then it makes SYNONYM 
less useful than it could be.

-- 
Gerry

[toc] | [next] | [standalone]

#45271

On Wednesday, 3 February 2016 12:47:00 UTC, Gerry  wrote:
> If we have:
> 
> 1234 value x
> synonym y x
> 
> Is this valid Forth?
> 
> 9876 to y
> 
> Relevant bits of the Forth 2012 standard are:
> 
> 6.2.2295 TO
> "An ambiguous condition exists if name was not defined by a word with "TO
> name run-time" semantics."
> 
> As y is defined by SYNONYM presumably the above is an ambiguous condition.
> 
> This seems wrong to me, after all one of the uses of SYNONYM is to 
> redefine a word with the same name in a different wordlist and that, 
> apparently cannot be done with VALUEs
> 
> Incidentally Gforth gives
> 
> 1234 value x  ok
> synonym y x  ok
> 9876 to y
> :3: error: Invalid name argument
> 9876 to >>>y<<<
> 
> Having written the above, I just realised that exactly the same question 
> applies to a SYNONYM of a deferred word and using IS on the synonym.
> 
> defer p
> synonym q p
> ' some-def is q
> 
> Again Gforth rejects this, but does accept
> ' some-def ' q defer!
> which works correctly.
> 
> If these uses of SYNONYM are ambiguous conditions then it makes SYNONYM 
> less useful than it could be.
> 
> -- 
> Gerry

Synonyms don't seem to offer any advantage over deferred words
AFAICS.

[toc] | [prev] | [next] | [standalone]

#45278

On Wed, 3 Feb 2016 05:36:56 -0800 (PST), Mark Wills
<markwills1970@gmail.com> wrote:

>Synonyms don't seem to offer any advantage over deferred words
>AFAICS.

The idea was that the synonym behaves in the same way as the
original word. So, ithe original has an optimiser, so does
the synonym. For a DEFERred word, this cannot be so because
the whole point of a DEFERred word is that its action may change
from use to use.

The law of unintended consequences always applies. Once the
language lawyers and "I can break anything" people got going
on SYNONYM, it turns out that the only (currently) foolproof
way to implement SYNONYM is to use a magic header bit to 
indicate that the word is a child of SYNONYM and for ' (tick)
of a synonym to return the original xt. It may sound really
dirty, but it has worked for a while on VFX without any
complaints. The implementation idea may have originated with
Bernd Paysan.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

#45280

On 03/02/2016 15:36, Stephen Pelc wrote:

> The law of unintended consequences always applies. Once the
> language lawyers and "I can break anything" people got going
> on SYNONYM, it turns out that the only (currently) foolproof
> way to implement SYNONYM is to use a magic header bit to
> indicate that the word is a child of SYNONYM and for ' (tick)
> of a synonym to return the original xt.

Surely another way is for a system to have detached headers so that the 
synonym's header points to the body of the old word. Assuming the xt is 
derived from the pointer (in my system it is the value of the pointer) 
the xt's are automatically the same.

>It may sound really
> dirty, but it has worked for a while on VFX without any
> complaints.

Trying synonyms of values and deferred words on VFX Forth shows that TO 
and IS do work with the synonyms

> The implementation idea may have originated with
> Bernd Paysan.

and Gforth does give the same xt for the original and synonym, but 
rejects TO and IS on the synonym (as Forth 2012 permits).

-- 
Gerry

[toc] | [prev] | [next] | [standalone]

#45711

Am Wed, 03 Feb 2016 17:26:17 +0000 schrieb Gerry Jackson:
>> The implementation idea may have originated with Bernd Paysan.
> 
> and Gforth does give the same xt for the original and synonym, but
> rejects TO and IS on the synonym (as Forth 2012 permits).

Yes, but I considder this as a bug.  Thanks for reporting.  This will be 
fixed.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#45713

On Wednesday, February 3, 2016 at 10:26:09 AM UTC-7, Gerry wrote:
> Gforth does give the same xt for the original and synonym, but 
> rejects TO and IS on the synonym (as Forth 2012 permits).

TO and IS will work with my system --- they have to be rewritten however so they will use my >BODY rather than the built-in >BODY --- this is trivial however (I have IS in the novice-package right now, and it is trivial).

[toc] | [prev] | [next] | [standalone]

#45295

On Wednesday, 3 February 2016 15:35:06 UTC, Stephen Pelc  wrote:
> On Wed, 3 Feb 2016 05:36:56 -0800 (PST), Mark Wills
> <markwills1970@gmail.com> wrote:
> 
> >Synonyms don't seem to offer any advantage over deferred words
> >AFAICS.
> 
> The idea was that the synonym behaves in the same way as the
> original word. So, ithe original has an optimiser, so does
> the synonym. For a DEFERred word, this cannot be so because
> the whole point of a DEFERred word is that its action may change
> from use to use.
> 

Good point. 

> The law of unintended consequences always applies. Once the
> language lawyers and "I can break anything" people got going
> on SYNONYM, it turns out that the only (currently) foolproof
> way to implement SYNONYM is to use a magic header bit to 
> indicate that the word is a child of SYNONYM and for ' (tick)
> of a synonym to return the original xt. It may sound really
> dirty, but it has worked for a while on VFX without any
> complaints. The implementation idea may have originated with
> Bernd Paysan.

Yes. I think that's the only way to do it.

[toc] | [prev] | [next] | [standalone]

#45299

Mark Wills <markwills1970@gmail.com> writes:

>On Wednesday, 3 February 2016 15:35:06 UTC, Stephen Pelc  wrote:
>> On Wed, 3 Feb 2016 05:36:56 -0800 (PST), Mark Wills
>> <markwills1970@gmail.com> wrote:
>>
>> >Synonyms don't seem to offer any advantage over deferred words
>> >AFAICS.
>>
>> The idea was that the synonym behaves in the same way as the
>> original word. So, ithe original has an optimiser, so does
>> the synonym. For a DEFERred word, this cannot be so because
>> the whole point of a DEFERred word is that its action may change
>> from use to use.
>>

>Good point.

>> The law of unintended consequences always applies. Once the
>> language lawyers and "I can break anything" people got going
>> on SYNONYM, it turns out that the only (currently) foolproof
>> way to implement SYNONYM is to use a magic header bit to
>> indicate that the word is a child of SYNONYM and for ' (tick)
>> of a synonym to return the original xt. It may sound really
>> dirty, but it has worked for a while on VFX without any
>> complaints. The implementation idea may have originated with
>> Bernd Paysan.

>Yes. I think that's the only way to do it.

It violates the first law of computation:
" If in trouble, simplify, not complexify"

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#45302

On 04 Feb 2016 11:32:25 GMT, Albert van der Horst
<albert@spenarnc.xs4all.nl> wrote:

>>> The law of unintended consequences always applies. Once the
>>> language lawyers and "I can break anything" people got going
>>> on SYNONYM, it turns out that the only (currently) foolproof
>>> way to implement SYNONYM is to use a magic header bit to
>>> indicate that the word is a child of SYNONYM and for ' (tick)
>>> of a synonym to return the original xt. It may sound really
>>> dirty, but it has worked for a while on VFX without any
>>> complaints. The implementation idea may have originated with
>>> Bernd Paysan.
>
>>Yes. I think that's the only way to do it.
>
>It violates the first law of computation:
>" If in trouble, simplify, not complexify"

Assuming that aliases (in whatever notation) are acceptable, 
changing SEARCH-WORDLIST to inspect an alias bit is a couple of
lines of code ... and the original word is always used. The only
user surprise comes with LOCATE and friends, but I can live with 
that.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

#45381

On Wednesday, February 3, 2016 at 8:35:06 AM UTC-7, Stephen Pelc wrote:
> The law of unintended consequences always applies. Once the
> language lawyers and "I can break anything" people got going
> on SYNONYM, it turns out that the only (currently) foolproof
> way to implement SYNONYM is to use a magic header bit to 
> indicate that the word is a child of SYNONYM and for ' (tick)
> of a synonym to return the original xt. It may sound really
> dirty, but it has worked for a while on VFX without any
> complaints. The implementation idea may have originated with
> Bernd Paysan.

The last time that the subject of SYNONYM came up, you very condescendingly told me to RTFM. You were referring to the VFX manual, as if I am supposed to care about VFX. You posted the code for your SYNONYM and it was not ANS-Forth. Now here you are again, saying that you need to have access to the header flag bits, which implies that your code is not ANS-Forth and must be vendor specific. 

You don't know enough about ANS-Forth to write SYNONYM in ANS-Forth, although I succeeded at doing this. Either that, or (more likely) you do know how to write SYNONYM in ANS-Forth, but you want to convince everybody that it is impossible so that they will buy VFX and all their code that uses SYNONYM will be locked in to VFX and will not work on any other ANS-Forth system.

I'll put my code in the next novice package release. Right now, here is my ANS-Forth code (also, you need the novice package, and you need the disambiguifiers):


: :synonym { xt flg str wid -- }            \ FLG is 1 for immediate and -1 for non-immediate
    str wid :name
    flg 1 = if      xt lit,  execute,  ;,  immediate        exit then
    flg -1 = if     xt compile,  ;,                         exit then
    true abort" *** :SYNONYM given an invalid xt ***" ;

: :synonym-fast-check ( -- )
    state @ 0= abort" *** a word created by :SYNONYM-FAST can't be used in interpretive mode ***" ;

: :synonym-fast { xt flg str wid -- }       \ FLG is 1 for immediate and -1 for non-immediate
    str wid :name
    flg 1 = if      xt lit,  execute,  ;,  immediate                exit then
    flg -1 = if     postpone :synonym-fast-check
                    xt lit,  postpone compile,  ;,  immediate       exit then
    true abort" *** :SYNONYM-FAST given an invalid xt ***" ;

: 'find ( -- xt flg )                       \ stream: name                  \ FLG is 1 for immediate and -1 for non-immediate
    bl word find  dup 0= abort" *** 'FIND couldn't find the word ***" ;

: synonym { wid | new -- }                  \ stream: new-name old-name     \ the new word is compiled into the WID word-list
    bl word hstr to new  
    'find  new  wid :synonym
    new dealloc ;

: synonym-fast { wid | new -- }             \ stream: new-name old-name     \ the new word is compiled into the WID word-list
    bl parse <hstr> to new
    'find  new  wid :synonym-fast
    new dealloc ;

\ :SYNONYM-FAST generates faster executing code than :SYNONYM but the words can't be used in interpretive mode.
\ This may not be necessary with a good optimizing compiler, but I'm not aware of any at this time.

1234512345 constant alias-id                \ an arbitrary number used to identify alias'd definitions

0
    w field alias.xt                        \ this should be the first field so the DOES> portion of ALIAS will be fast (no addition needed)
    w field alias.adr                       \ the address of the body, used to identify alias'd definitions
    w field alias.id                        \ the constant ALIAS-ID,   used to identify alias'd definitions
constant alias-struct

: alias ( wid -- )                          \ stream: new-name old-name     \ the new word is compiled into the WID word-list
    get-current  swap set-current  create  set-current
        here >r  alias-struct allot
        'find if  immediate  then   r@ alias.xt !
        r@                          r@ alias.adr !
        alias-id                    r@ alias.id !
        rdrop
    does>
        alias.xt @  execute ;

\ ALIAS does the same thing as SYNONYM but has the advantage that >BODY will work on it. 
\ It is slower executing though (especially under SwiftForth in which CREATE DOES> words are very inefficient).

: >body ( xt -- adr )
    >body >r
    r@ alias.adr @  r@ = if  r@ alias.id @  alias-id = if                   \ is this an alias'd word?
        r> alias.xt @  >body  exit then then                                \ return the body of the original word
    r> ;                                                                    \ return the body of this word

\ Note that >BODY still has an undefined result if used on a word that wasn't defined with CREATE or isn't an alias of such a word.

[toc] | [prev] | [next] | [standalone]

#45792

Am Mon, 08 Feb 2016 22:03:17 -0800 schrieb hughaguilar96:

> You don't know enough about ANS-Forth to write SYNONYM in ANS-Forth,
> although I succeeded at doing this.

No, you didn't quite, you e.g. didn't succeed with synonyms of values, 
where TO <synonym> works, or synonyms of deferred words, where IS 
<synonym> works.

Though, of course, the Forth-2012 spec does not say that "to newname" has 
the same semantics as "to oldname", and also for IS and DEFER@ (deferred 
words).  Or that ' newname execute and ' newname compile, always will do 
the same as ' oldname execute and ' oldname compile,.  So you succeeded 
in creating a synonym that actually does what's specified, but no more.

A quality implementation should behave well on all that, and that's 
impossible in ANS Forth, which is the actual reason for having SYNONYM in 
the standard instead of in a library.  You can certainly argue that the 
Forth-2012 standard fell short, by only requiring those parts to work on 
a synonym, where your ANS Forth implementation already works, and it 
should more than just that.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#45793

On Wednesday, March 2, 2016 at 5:12:13 PM UTC-7, Bernd Paysan wrote:
> Am Mon, 08 Feb 2016 22:03:17 -0800 schrieb hughaguilar96:
> 
> > You don't know enough about ANS-Forth to write SYNONYM in ANS-Forth,
> > although I succeeded at doing this.
> 
> No, you didn't quite, you e.g. didn't succeed with synonyms of values, 
> where TO <synonym> works, or synonyms of deferred words, where IS 
> <synonym> works.
> 
> Though, of course, the Forth-2012 spec does not say that "to newname" has 
> the same semantics as "to oldname", and also for IS and DEFER@ (deferred 
> words).  Or that ' newname execute and ' newname compile, always will do 
> the same as ' oldname execute and ' oldname compile,.  So you succeeded 
> in creating a synonym that actually does what's specified, but no more.
> 
> A quality implementation should behave well on all that, and that's 
> impossible in ANS Forth, which is the actual reason for having SYNONYM in 
> the standard instead of in a library.  You can certainly argue that the 
> Forth-2012 standard fell short, by only requiring those parts to work on 
> a synonym, where your ANS Forth implementation already works, and it 
> should more than just that.

I have >BODY that works with synonyms, giving the pfa of the original word. IS and TO are defined in terms of >BODY so they will work, but they have to be rewritten so they use my >BODY rather than the built-in >BODY that doesn't work.

All of you committee members are too quick to use the word "impossible" --- you are focused on telling Forthers what they can't do --- by comparison, I tell Forthers what they can do.

[toc] | [prev] | [next] | [standalone]

#45277

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>If we have:
>
>1234 value x
>synonym y x
>
>Is this valid Forth?
>
>9876 to y

It's not Forth-2012, because y only has the interpretation and
compilation semantics of x, but not the "TO x run-time semantics".

>Relevant bits of the Forth 2012 standard are:
>
>6.2.2295 TO
>"An ambiguous condition exists if name was not defined by a word with “TO
>name run-time” semantics."
>
>As y is defined by SYNONYM presumably the above is an ambiguous condition.

Yes.

>Having written the above, I just realised that exactly the same question 
>applies to a SYNONYM of a deferred word and using IS on the synonym.

Yes.

>If these uses of SYNONYM are ambiguous conditions then it makes SYNONYM 
>less useful than it could be.

Yes, SYNONYM would be more useful if it would copy all the semantics
of a word.  That leads to the question: Should it give the same xt?
The same nt?  In the latter case, NAME>STRING would give the name of
the old word, not net name of the synonym.

Is there somebody willing to make a proposal on that?  And will we
find consensus?

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

[toc] | [prev] | [next] | [standalone]

#45282

On 03/02/2016 15:16, Anton Ertl wrote:
> Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>
>> If these uses of SYNONYM are ambiguous conditions then it makes SYNONYM
>> less useful than it could be.
>
> Yes, SYNONYM would be more useful if it would copy all the semantics
> of a word.  That leads to the question: Should it give the same xt?
> The same nt?  In the latter case, NAME>STRING would give the name of
> the old word, not net name of the synonym.
>
> Is there somebody willing to make a proposal on that?  And will we
> find consensus?

A proposal on what exactly. The options seem to be:
- all the original words semantics are copied to the synonym (that's 
already implied in the specification of SYNONYM isn't it?)
- TO and IS work with synonyms of VALUEs and deferred words
- ticking a synonym returns the same xt as for the original word
- obtaining the nt of a synonym shoulds give the same nt as the 
original. IIRC the only standard way to obtain an nt is using 
TRAVERSE-WORDLIST and providing a word that does a string comparison, in 
which case the nt's are likely to be different?

-- 
Gerry

[toc] | [prev] | [next] | [standalone]

#45284

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:

>- obtaining the nt of a synonym shoulds give the same nt as the
>original. IIRC the only standard way to obtain an nt is using
>TRAVERSE-WORDLIST and providing a word that does a string comparison, in
>which case the nt's are likely to be different?

This serves to show that nt (name token) is a bad name.
I'm a proponent of dea (dictionary entry address).

Name token suggest that the name identifies the entry.
By definition this makes it impossible to make entries the same
and have the name different.

>Gerry

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#45286

On 03/02/2016 20:09, Albert van der Horst wrote:
> Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>
>> - obtaining the nt of a synonym shoulds give the same nt as the
>> original. IIRC the only standard way to obtain an nt is using
>> TRAVERSE-WORDLIST and providing a word that does a string comparison, in
>> which case the nt's are likely to be different?
>
> This serves to show that nt (name token) is a bad name.
> I'm a proponent of dea (dictionary entry address).
>
> Name token suggest that the name identifies the entry.
> By definition this makes it impossible to make entries the same
> and have the name different.

If a system has headers separated from the body and the synonym headers 
point to the same body, if the name token points to the header (isn't 
that the same as your dea?) they will have different name tokens but 
with the same body.

-- 
Gerry

[toc] | [prev] | [next] | [standalone]

#45289

On 2/3/16 10:52 AM, Gerry Jackson wrote:
> On 03/02/2016 20:09, Albert van der Horst wrote:
>> Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>>
>>> - obtaining the nt of a synonym shoulds give the same nt as the
>>> original. IIRC the only standard way to obtain an nt is using
>>> TRAVERSE-WORDLIST and providing a word that does a string comparison, in
>>> which case the nt's are likely to be different?
>>
>> This serves to show that nt (name token) is a bad name.
>> I'm a proponent of dea (dictionary entry address).
>>
>> Name token suggest that the name identifies the entry.
>> By definition this makes it impossible to make entries the same
>> and have the name different.
>
> If a system has headers separated from the body and the synonym headers
> point to the same body, if the name token points to the header (isn't
> that the same as your dea?) they will have different name tokens but
> with the same body.
>

The point of the designation "name token" is that it provides access to 
the name. It's wildly unlikely that there will ever be a consensus on 
the structure of a "header" (they differ dramatically from one system to 
another, including the possibility of being separate from the body). A 
"name" is the only thing that we could agree on, and even then its 
structure is ambiguous.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#45298

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:

>On 03/02/2016 20:09, Albert van der Horst wrote:
>> Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>>
>>> - obtaining the nt of a synonym shoulds give the same nt as the
>>> original. IIRC the only standard way to obtain an nt is using
>>> TRAVERSE-WORDLIST and providing a word that does a string comparison, in
>>> which case the nt's are likely to be different?
>>
>> This serves to show that nt (name token) is a bad name.
>> I'm a proponent of dea (dictionary entry address).
>>
>> Name token suggest that the name identifies the entry.
>> By definition this makes it impossible to make entries the same
>> and have the name different.

>If a system has headers separated from the body and the synonym headers
>point to the same body, if the name token points to the header (isn't
>that the same as your dea?) they will have different name tokens but
>with the same body.

I talk about terminology. The presence of dea's can't be avoided.
There must be a header somewhere (or more abstract mechanism)
that allows to find all properies of a Forth word. A name token
is not a good terminology. (Just "token" would be much better.)

Look at python
a = b
you can refer to the object that is by the
name b by using the name b, no surprise.
After the assignment you can also use the name a.
The identification that is passed is probably a memory address,
but only implementors ever see it.

Names are so unessential. The queen of Holland with a full
name that runs over pages, is referred to by the dauphin as
"ma".

>--
>Gerry

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#45294

On Wednesday, 3 February 2016 18:26:09 UTC, Gerry  wrote:
> - obtaining the nt of a synonym shoulds give the same nt as the 
> original. 

I'd take issue with that. A name token should return the name token of
the word, not it's "parent". There may be times when you want to display
the name of the word (step by step debuggers etc).

Agree re the XT.

My implementation doesn't properly comply. It works for variables but
not values. If you create a synonym of an immediate word the synonym
will be immediate too, but it has its own XT. 

 
--BLOCK-00046---------
: SYNONYM ( "new-word" "old-word" -- )
  CREATE  BL WORD FIND DUP IF
    SWAP , IMMEDIATE 1+ IF
      DOES> @ EXECUTE
    ELSE
      DOES> STATE @ IF
        @ ,
      ELSE
        @ EXECUTE
      THEN
    THEN
  ELSE
    TRUE ABORT" Word not found"
  THEN ;
 
.( SYNONYM loaded.) .( Usage: SYNONYM NewWord OldWord)

[toc] | [prev] | [next] | [standalone]

#45301

Mark Wills <markwills1970@gmail.com> writes:
>I'd take issue with that. A name token should return the name token of
>the word, not it's "parent". There may be times when you want to display
>the name of the word (step by step debuggers etc).
>
>Agree re the XT.

Debuggers and decompilers usually don't have the nt available; in
indirect=-threaded code, they have the CFA, which is probably used as
xt, so if the synonym has the same xt, the decompiler/debugger will
decompile the same name.  Which is not a problem, because decompilers
(and debuggers) are a best-effort issue anyway, and programmers tend
to accept this (e.g., native-code compilers typically show assembly
code as output of SEE).

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.forth

csiph-web