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 2 of 2 — ← Prev page 1 [2]

#45296

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>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?)

What the specification specifies is that interpretation and
compilation semantics are copied, nothing else.

>- TO and IS work with synonyms of VALUEs and deferred words

Another interesting case is DOES>.  Does applying DOES> to the synonym
of a CREATEd word affect the original or not?

Applying IMMEDIATE to newword is already explicitly ambiguous.

>- ticking a synonym returns the same xt as for the original word

I see no protests against that yet.

>- obtaining the nt of a synonym shoulds give the same nt as the 
>original.

That seems to be controversial.  So either require a different nt, or
allow both implementations.

>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?

If they are the same, newword will just not be found with that method.
A consequence of such an implementation would be that a WORDS defined
using TRAVERSE-WORDLIST would have the following effect; given the
program

vocabulary w also w definitions
create foo
synonym bar foo
words

the output would be "foo foo".  I guess that's not desired, so I think
we should require a different nt.

- 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]

#45300

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote in message
news:2016Feb4.115447@mips.complang.tuwien.ac.at...
> Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
> ...
> >- ticking a synonym returns the same xt as for the original word
>
> I see no protests against that yet.

Forth Inc's synonyms don't return the same xt.  If it were an issue
I'd expect their users to have protested against it.

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

#45283

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

>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.

Or it just proves that parsing words are evil ...

>--
>Gerry
-- 
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]

#45288

Albert van der Horst 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.
>
> Or it just proves that parsing words are evil ...

Or that Standardizing results in expectations that are too high.  Forth Inc's AKA
is effected using a JMP instruction.  It seems to work for them.

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

#45297

Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>>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.
>
>Or it just proves that parsing words are evil ...

While parsing words are evil, this case does not show that.  It just
shows that we did not build a word-type check into DEFER!, while we
perform such a check at text interpretation time in IS. The reason is
that DEFER!  might occur inside a tight loop and a check could have a
measurable impact, while the text interpretation of IS costs so much
(and is therefore so rare) that the word-type check is peanuts in that
context.

- 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] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web