On 2021-06-04 10:15, Ruvim wrote:
> On 2021-05-30 19:59, Anton Ertl wrote:
>> Ruvim <ruvim.pinka@gmail.com> writes:
>>> On 2021-05-29 20:36, Anton Ertl wrote:
[...]
>>>> Of course, the other problem is that some Forth systems implement
>>>> EXECUTE in a way that puts stuff on the return stack around the
>>>> execution, so these systems work like your E.  Given that nobody
>>>> complains about that, maybe EXECUTE's definition should be refined
>>>> appropriately, "solving" all the problems with "can I EXECUTE the xt of
>>>> <return-stack-accessing-word>".
>>>
>>> I think, this problem was solved via disallowance of obtaining the xt of
>>> <return-stack-accessing-word> (since such words have undefined
>>> interpretation semantics).
>>
>> Yes, but I think we should put this possible effect of EXECUTE in
>> EXECUTE,
>
> It's not easy, since the behavior of "EXECUTE" should be broken up into
> three phases for that.
>
> Another question is, should this possible effect be also put in "CATCH",
> "EVALUATE", "INCLUDED"?
>
>
>
>> and also put a related limitation on the text interpreter,
>
> That it shouldn't use the return stack? Or what the limitation?
>
>
>
>> and delete the undefinition of the interpretation semantics of >R etc.
>>
>> This would make
>>
>> : foo [ ' >r compile, ] r> ;
>>
>> standard.
>
> I dislike this latter idea, since it makes nonstandard the existing
> dual-semantics implementations for R-words.

One more problem with this approach is an inconsistency concerning
redefinitions.

An R-related word can be redefined only as an immediate word.
E.g.:

: exit ( some stuff ) postpone exit ; immediate
: >r ( some stuff ) postpone >r ; immediate

And after such a redefinition, the phrase
['] >r compile,
or
[ ' >r compile, ]

produces the different effects than before the redefinition.

It's the same problem as about "[compile]", when the phrase
[compile] exit

produces the different effects after a redefinition of "exit", than
before the redefinition.

The capability to redefine words is very important in Forth, I believe.

If we want to keep this capability, the standard should not allow to
obtain the execution token for R-related words (regardless of the
definition for interpretation semantics for them), since that produces
an intrinsic inconsistency.

--
Ruvim

Ruvim <ruvim.pinka@gmail.com> writes:
>On 2021-06-04 10:15, Ruvim wrote:
>> On 2021-05-30 19:59, Anton Ertl wrote:
>>> Ruvim <ruvim.pinka@gmail.com> writes:
>>>> On 2021-05-29 20:36, Anton Ertl wrote:
>[...]
>>>>> Of course, the other problem is that some Forth systems implement
>>>>> EXECUTE in a way that puts stuff on the return stack around the
>>>>> execution, so these systems work like your E.  Given that nobody
>>>>> complains about that, maybe EXECUTE's definition should be refined
>>>>> appropriately, "solving" all the problems with "can I EXECUTE the xt of
>>>>> <return-stack-accessing-word>".
>>>>
>>>> I think, this problem was solved via disallowance of obtaining the xt of
>>>> <return-stack-accessing-word> (since such words have undefined
>>>> interpretation semantics).
>>>
>>> Yes, but I think we should put this possible effect of EXECUTE in
>>> EXECUTE,
>>
>> It's not easy, since the behavior of "EXECUTE" should be broken up into
>> three phases for that.

Instead of:

|Remove xt from the stack and perform the semantics identified by
|it. Other stack effects are due to the word EXECUTEd.

we would write:

|Remove xt from the stack and push nest-sys on the return stack.
|Perform the semantics identified by xt. Remove nest-sys from the
|return stack. Other stack effects are due to the word EXECUTEd.

>> Another question is, should this possible effect be also put in "CATCH",

Catch already specifies that it pushes an exception frame on the
exception stack, which may be the return stack. So >R etc. cannot be
CATCHed in a standard program.

>> "EVALUATE", "INCLUDED"?

That follows from the text interpreter restriction.

>>> and also put a related limitation on the text interpreter,
>>
>> That it shouldn't use the return stack? Or what the limitation?

The text interpreter pushes nest-sys before performing the
interpretation semantics and pops it afterwards.

>>> and delete the undefinition of the interpretation semantics of >R etc.
>>>
>>> This would make
>>>
>>> : foo [ ' >r compile, ] r> ;
>>>
>>> standard.
>>
>> I dislike this latter idea, since it makes nonstandard the existing
>> dual-semantics implementations for R-words.

Which implementations exist that would become non-standard?

The following example works on Gforth, iForth*, SwiftForth, and VFX:

: foo [ ' >r compile, ] r> ; 1 foo . \ prints 1

* iForth works if you first define : compile, compile, ;

>One more problem with this approach is an inconsistency concerning
>redefinitions.
>
>An R-related word can be redefined only as an immediate word.
>E.g.:
>
> : exit ( some stuff ) postpone exit ; immediate
> : >r ( some stuff ) postpone >r ; immediate
>
>And after such a redefinition, the phrase
> ['] >r compile,
>or
> [ ' >r compile, ]
>
>produces the different effects than before the redefinition.
>
>
>It's the same problem as about "[compile]", when the phrase
> [compile] exit
>
>produces the different effects after a redefinition of "exit", than
>before the redefinition.
>
>
>The capability to redefine words is very important in Forth, I believe.

We have SYNONYM for that, so in theory we should be able to do

synonym >r1 >r : foo [ ' >r1 compile, ] r> ; 1 foo . \ prints 1

In practice it works on Gforth and VFX 5.11. The version of iForth I
use does not have SYNONYM, and SwiftForth has a broken implementation.

Let's ignore SYNONYM for no: Then the question is whether the
programmers are better off if they cannot COMPILE, the xt of >R at
all, than if they can do it, but cannot define a word with the same
capability?

For the FIND-based user-defined text interpreter there is also the
issue that FIND returns -1 for >R on many systems, and in compile
state that text-interpreter then calls COMPILE, for the xt returned by
FIND.

In any case, if we want to make this clear, >R etc. should become
words with definitions like

compilation: append the run-time semantics below to the current definition.

run-time: ... (what is currently the execution semantics).

I think we should certainly do that for EXIT, but the case wrt. >R
etc. is less clear to me.

- 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 2021: https://euro.theforth.net/2021

On 2021-06-05 14:55, Anton Ertl wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
>> On 2021-06-04 10:15, Ruvim wrote:
>>> On 2021-05-30 19:59, Anton Ertl wrote:
>>>> Ruvim <ruvim.pinka@gmail.com> writes:
>>>>> On 2021-05-29 20:36, Anton Ertl wrote:
>> [...]
>>>>>> Of course, the other problem is that some Forth systems implement
>>>>>> EXECUTE in a way that puts stuff on the return stack around the
>>>>>> execution, so these systems work like your E.  Given that nobody
>>>>>> complains about that, maybe EXECUTE's definition should be refined
>>>>>> appropriately, "solving" all the problems with "can I EXECUTE the xt of
>>>>>> <return-stack-accessing-word>".
>>>>>
>>>>> I think, this problem was solved via disallowance of obtaining the xt of
>>>>> <return-stack-accessing-word> (since such words have undefined
>>>>> interpretation semantics).
>>>>
>>>> Yes, but I think we should put this possible effect of EXECUTE in
>>>> EXECUTE,
>>>
>>> It's not easy, since the behavior of "EXECUTE" should be broken up into
>>> three phases for that.
>
> Instead of:
>
> |Remove xt from the stack and perform the semantics identified by
> |it. Other stack effects are due to the word EXECUTEd.
>
> we would write:
>
> |Remove xt from the stack and push nest-sys on the return stack.
> |Perform the semantics identified by xt. Remove nest-sys from the
> |return stack. Other stack effects are due to the word EXECUTEd.

Yes, you have added two steps. It simpler than I thought. Agreed.

I just would also make a better wording concerning "EXECUTEd" and self
referencing, as:

| Other stack effects are due to the semantics performed.

>>> Another question is, should this possible effect be also put in "CATCH",
>
> Catch already specifies that it pushes an exception frame on the
> exception stack, which may be the return stack. So >R etc. cannot be
> CATCHed in a standard program.

Yes, agreed.

>>> "EVALUATE", "INCLUDED"?
>
> That follows from the text interpreter restriction.
>
>>>> and also put a related limitation on the text interpreter,
>>>
>>> That it shouldn't use the return stack? Or what the limitation?
>
> The text interpreter pushes nest-sys before performing the
> interpretation semantics and pops it afterwards.

Ah, yes, agreed. But it isn't a limitation on the text interpreter, but
a limitation on a program.

>>>> and delete the undefinition of the interpretation semantics of >R etc.
>>>>
>>>> This would make
>>>>
>>>> : foo [ ' >r compile, ] r> ;
>>>>
>>>> standard.
>>>
>>> I dislike this latter idea, since it makes nonstandard the existing
>>> dual-semantics implementations for R-words.
>
> Which implementations exist that would become non-standard?

Any single-xt (and, as I expect, almost any dual-xt) implementation
where "FIND" returns n value 1 for ">r" in compilation state, is affected.

For example, SP-Forth/4

> The following example works on Gforth, iForth*, SwiftForth, and VFX:
>
> : foo [ ' >r compile, ] r> ; 1 foo . \ prints 1
>
> * iForth works if you first define : compile, compile, ;
>

>> One more problem with this approach is an inconsistency concerning
>> redefinitions.
>>
>> An R-related word can be redefined only as an immediate word.
>> E.g.:
>>
>> : exit ( some stuff ) postpone exit ; immediate
>> : >r ( some stuff ) postpone >r ; immediate
>>
>> And after such a redefinition, the phrase
>> ['] >r compile,
>> or
>> [ ' >r compile, ]
>>
>> produces the different effects than before the redefinition.
>>
>>
>> It's the same problem as about "[compile]", when the phrase
>> [compile] exit
>>
>> produces the different effects after a redefinition of "exit", than
>> before the redefinition.
>>
>>
>> The capability to redefine words is very important in Forth, I believe.
>
> We have SYNONYM for that, so in theory we should be able to do
>
> synonym >r1 >r : foo [ ' >r1 compile, ] r> ; 1 foo . \ prints 1

But you have miss "some stuff", that I mean some additional code, as:

: >r ... postpone >r ... ; immediate

> In practice it works on Gforth and VFX 5.11. The version of iForth I
> use does not have SYNONYM, and SwiftForth has a broken implementation.
>
> Let's ignore SYNONYM for no: Then the question is whether the
> programmers are better off if they cannot COMPILE, the xt of >R at
> all, than if they can do it, but cannot define a word with the same
> capability?

This dilemma is incorrect.

1. At the moment, the programmers cannot obtain xt of ">R", so they also
cannot apply "COMPILE," to it.

2. The programmers don't need to compile the xt of ">R", actually they
need to append the run-time semantics of ">R".

3. In any case, they can append these semantics via "POSTPONE >R"

4. The problem of redefinition is not only in a word with the same
semantics, but it is also in a word with additional (hidden) semantics.
E.g., for logging, checking a stack balance, debugging, etc.

5. Redefinitions that work before that, will be incompatible with the
new code (that may tick ">R").

Thus, the programmers will lost ability for redefinition, and they won't
get anything new in return, just one *additional* way to append run-time
semantics of ">R".

> For the FIND-based user-defined text interpreter there is also the
> issue that FIND returns -1 for >R on many systems, and in compile
> state that text-interpreter then calls COMPILE, for the xt returned by
> FIND.

Why do you think that it's an issue?

It's allowed and compatible at the moment.

In the general case, when "FIND" is applied to the ">R" string, an xt
that it returns in compilation state is not the xt for the ">R" word.
It's the xt of an internal definition that serves to perform the
compilation semantics for the ">R" word.

> In any case, if we want to make this clear, >R etc. should become
> words with definitions like
>
> compilation: append the run-time semantics below to the current definition.
>
> run-time: ... (what is currently the execution semantics).
>
> I think we should certainly do that for EXIT, but the case wrt. >R
> etc. is less clear to me.

On these I agree.

--
Ruvim

On Saturday, June 5, 2021 at 5:31:40 AM UTC-7, Anton Ertl wrote:
> >The capability to redefine words is very important in Forth, I believe.
> We have SYNONYM for that, so in theory we should be able to do
>
> synonym >r1 >r : foo [ ' >r1 compile, ] r> ; 1 foo . \ prints 1
>
> In practice it works on Gforth and VFX 5.11. The version of iForth I
> use does not have SYNONYM, and SwiftForth has a broken implementation.

Given the disambiguifiers, it is easy to write SYNONYM FAST-SYNONYM and ALIAS.
If SYNONYM works in both Gforth and VFX, then you must be using disambiguifiers
internally.

On Saturday, June 5, 2021 at 2:31:40 PM UTC+2, Anton Ertl wrote:
> >The capability to redefine words is very important in Forth, I believe.
> We have SYNONYM for that, so in theory we should be able to do
>
> synonym >r1 >r : foo [ ' >r1 compile, ] r> ; 1 foo . \ prints 1
>
> In practice it works on Gforth and VFX 5.11. The version of iForth I
> use does not have SYNONYM, and SwiftForth has a broken implementation.

a) It depends. Redefining words using SYNONYM can be useful sometimes.

However, if I would want to redefine a troublesome word, I would just use SEE to look up
the code of the original word and define the new word using the same code.

In your example you want to redefine >R under the new name >R1.
In SwiftForth, >R is just a tiny assembly instruction (4 Intel instructions). Defining >R1
again instead of using a synonym may cost you a few bytes. But on the other hand you can be sure
that the new word works as intended; it does not need sophisticated testing for special cases.

b) In order to create synonyms, SwiftForth always had the word AKA which is super simple:
: AKA ( -- ) ' >CODE HEADER ,JMP ;
\ AKA <old> <new>

My only gripe with AKA is that it expects the two arguments in the wrong order.
The following definition makes more sense and is good enough for my needs:
: ALIAS ( -- ) HEADER ' >CODE ,JMP ;
\ ALIAS <new> <old>

c) SwiftForth has added SYNONYM recently, in SF version 3.11.0. This word has a more
complicated definition than ALIAS, but it handles special cases where ALIAS would fail.

I have tested SYNONYM and did not see anything wrong with it. Can you please tell me
why you think the implementation is broken? In a meaningful example?

Henry

On 2021-06-05 18:29, Ruvim wrote:
> On 2021-06-05 14:55, Anton Ertl wrote:
>> Ruvim <ruvim.pinka@gmail.com> writes:
>>> On 2021-06-04 10:15, Ruvim wrote:
>>>> On 2021-05-30 19:59, Anton Ertl wrote:
[...]
>>>>> and delete the undefinition of the interpretation semantics of >R etc.
>>>>>
>>>>> This would make
>>>>>
>>>>> : foo [ ' >r compile, ] r> ;
>>>>>
>>>>> standard.
>>>>
>>>> I dislike this latter idea, since it makes nonstandard the existing
>>>> dual-semantics implementations for R-words.
[...]
>>> One more problem with this approach is an inconsistency concerning
>>> redefinitions.
>>>
[...]
>> Let's ignore SYNONYM for no: Then the question is whether the
>> programmers are better off if they cannot COMPILE, the xt of >R at
>> all, than if they can do it, but cannot define a word with the same
>> capability?
>
> This dilemma is incorrect.
>
> 1. At the moment, the programmers cannot obtain xt of ">R", so they also
> cannot apply "COMPILE," to it.
>
> 2. The programmers don't need to compile the xt of ">R", actually they
> need to append the run-time semantics of ">R".
>
> 3. In any case, they can append these semantics via "POSTPONE >R"
>
> 4. The problem of redefinition is not only in a word with the same
> semantics, but it is also in a word with additional (hidden) semantics.
> E.g., for logging, checking a stack balance, debugging, etc.
>
> 5. Redefinitions that work before that, will be incompatible with the
> new code (that may tick ">R").
>
>
> Thus, the programmers will lost ability for redefinition, and they won't
> get anything new in return, just one *additional* way to append run-time
> semantics of ">R".

One more argument: There is no much sense to remove prohibition of
obtaining xt for a word, if you cannot apply "execute" to the returned
xt anyway.

An example for the item 5 above is my "c-state" library[1] to support
multiple compilation (or postponing) levels.

It redefines ">R" (and many other words) in the following way:

: >r [: postpone >r ;] et-xt ; immediate

This standard code is incompatible with a program that may tick ">R".

[1] The redefinitions (wrappers) are in the "c-state.wrappers.fth" file
at https://git.io/JZvco

>> For the FIND-based user-defined text interpreter there is also the
>> issue that FIND returns -1 for >R on many systems, and in compile
>> state that text-interpreter then calls COMPILE, for the xt returned by
>> FIND.
>
> Why do you think that it's an issue?
>
> It's allowed and compatible at the moment.
>
> In the general case, when "FIND" is applied to the ">R" string, an xt
> that it returns in compilation state is not the xt for the ">R" word.
> It's the xt of an internal definition that serves to perform the
> compilation semantics for the ">R" word.
>

--
Ruvim

On 6/06/2021 23:17, Heinrich Hohl wrote:
> ...
> b) In order to create synonyms, SwiftForth always had the word AKA which is super simple:
> : AKA ( -- ) ' >CODE HEADER ,JMP ;
> \ AKA <old> <new>
>
> My only gripe with AKA is that it expects the two arguments in the wrong order.

“Freedom is the freedom to say that two plus two make four."

Heinrich Hohl <hheinrich.hohl@gmail.com> writes:
>On Saturday, June 5, 2021 at 2:31:40 PM UTC+2, Anton Ertl wrote:
>> >The capability to redefine words is very important in Forth, I believe.
>> We have SYNONYM for that, so in theory we should be able to do
>>
>> synonym >r1 >r : foo [ ' >r1 compile, ] r> ; 1 foo . \ prints 1
>>
>> In practice it works on Gforth and VFX 5.11. The version of iForth I
>> use does not have SYNONYM, and SwiftForth has a broken implementation.
>
>a) It depends. Redefining words using SYNONYM can be useful sometimes.
>
>However, if I would want to redefine a troublesome word, I would just use SEE to look up
> the code of the original word and define the new word using the same code.
>
>In your example you want to redefine >R under the new name >R1.
>In SwiftForth, >R is just a tiny assembly instruction (4 Intel instructions). Defining >R1
>again instead of using a synonym may cost you a few bytes. But on the other hand you can be sure
>that the new word works as intended; it does not need sophisticated testing for special cases.

Let's see:

: foo [ ' >r compile, ] r> ; 1 foo .

works on SwiftForth 3.11.

I define >R1 using the source code definition of >R:

ICODE >R1 ( x -- ) ( R: -- x )
EBX PUSH POP(EBX) RET END-CODE

: foo1 [ ' >r1 compile, ] r> ; 1 foo1 .

This works, too. Great! I guess the ICODE (instead of CODE) means
that COMPILE, inlines the code.

>b) In order to create synonyms, SwiftForth always had the word AKA which is super simple:
>: AKA ( -- ) ' >CODE HEADER ,JMP ;
>\ AKA <old> <new>

Starting with a fresh SwiftForth 3.11, I type in:

aka >r >r1 : foo [ ' >r1 compile, ] r> ; 1 foo .

This produces a segmentation fault, because FOO calls >R1, and
eventually >R, but SwiftForth's >R is designed to be inlined, not
called. For the same reason, you cannot EXECUTE the xt of >R.

>c) SwiftForth has added SYNONYM recently, in SF version 3.11.0. This word has a more
>complicated definition than ALIAS, but it handles special cases where ALIAS would fail.

And it fails in cases where AKA and ALIAS work.

>I have tested SYNONYM and did not see anything wrong with it. Can you please tell me
>why you think the implementation is broken? In a meaningful example?

It produces STATE-smart words. Short examples tend to be contrived,
and meaningful examples tend to be long; I'll go for a short one and
leave it to you to imagine a meaningful one:

: foo1 ." foo" ;
synonym foo2 foo1
defer bar immediate
' foo1 is bar
: bla1 bar ; \ prints "foo"
bla1 \ prints nothing
' foo2 is bar
: bla2 bar ; \ prints "foo"
bla2 \ prints nothing

Works in development Gforth and VFX 5.11, but the output of the last
two lines is wrong in SwiftForth. I.e., FOO2 does not behave as
SYNONYM in SwiftForth.

- 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 2021: https://euro.theforth.net/2021

On Sunday, June 6, 2021 at 7:55:01 PM UTC+2, Anton Ertl wrote:
> Starting with a fresh SwiftForth 3.11, I type in:
> : foo1 ." foo" ;
> synonym foo2 foo1
> defer bar immediate
> ' foo1 is bar
> : bla1 bar ; \ prints "foo"
> bla1 \ prints nothing
> ' foo2 is bar
> : bla2 bar ; \ prints "foo"
> bla2 \ prints nothing

Hello Anton,

thank you for the explanations. These are simple but good examples.

Now I see the shortcomings in SwiftForth's SYNONYM. And it is quite
surprising that the much simpler AKA handles these examples properly.
I have learned something today!

Henry

On Saturday, June 5, 2021 at 2:21:34 AM UTC-7, Ruvim wrote:
> An R-related word can be redefined only as an immediate word.
> E.g.:
>
> : exit ( some stuff ) postpone exit ; immediate
> : >r ( some stuff ) postpone >r ; immediate

Ruvim has invented disambiguifiers!

Here are some disambiguifiers from the novice-package (there are 53 disambiguifiers total):
: exit state @ 0= abort" *** no interpretation semantics for: EXIT ***"
postpone exit ; immediate
: >r state @ 0= abort" *** no interpretation semantics for: >R ***"
postpone >r ; immediate

> And after such a redefinition, the phrase
> ['] >r compile,
> or
> [ ' >r compile, ]
>
> produces the different effects than before the redefinition.

They are called "disambiguifiers" because they produce the same result
for all ANS-Forth implementations. Previously, these words were ambiguous
so they produced different results for various ANS-Forth implementations.
In some cases (but not other cases) the effect of the disambiguifier will be
different from that of the raw ANS-Forth word.
This is not a problem --- just ignore raw ANS-Forth and always assume that
you have the disambiguifiers, so you always get the same result.

> It's the same problem as about "[compile]", when the phrase
> [compile] exit
>
> produces the different effects after a redefinition of "exit", than
> before the redefinition.

It's the same problem with all 53 ambiguous words in ANS-Forth.

You seem to be stuck trying to figure out certain words, such as EXIT
and >R --- you don't realize that this is a general problem in ANS-Forth

> The capability to redefine words is very important in Forth, I believe.

Well, yeah!

> If we want to keep this capability, the standard should not allow to
> obtain the execution token for R-related words (regardless of the
> definition for interpretation semantics for them), since that produces
> an intrinsic inconsistency.

Bullshit!
ANS-Forth's ambiguity in FIND can be fixed with the disambiguifiers.

You are struggling to solve a problem that I solved years ago.
You seem to be on the verge of inventing disambiguifiers though. Yay!
If you do invent disambiguifiers, Elizabeth Rather's Committee of Can't
will tell you that you are no longer a Forth programmer at all.

On 7/06/2021 06:03, Heinrich Hohl wrote:
> On Sunday, June 6, 2021 at 7:55:01 PM UTC+2, Anton Ertl wrote:
>> Starting with a fresh SwiftForth 3.11, I type in:
>> : foo1 ." foo" ;
>> synonym foo2 foo1
>> defer bar immediate
>> ' foo1 is bar
>> : bla1 bar ; \ prints "foo"
>> bla1 \ prints nothing
>> ' foo2 is bar
>> : bla2 bar ; \ prints "foo"
>> bla2 \ prints nothing
>
> Hello Anton,
>
> thank you for the explanations. These are simple but good examples.
>
> Now I see the shortcomings in SwiftForth's SYNONYM.

It was only recently added. Clearly not fully tested.

> And it is quite
> surprising that the much simpler AKA handles these examples properly.

OTOH their AKA doesn't promote immediacy:

: foo1 ." foo" ; immediate

aka foo1 foo2

: bla1 foo1 ; \ prints "foo"
bla1 \ prints nothing

: bla2 foo2 ; \ prints nothing
bla2 \ prints "foo"

DX-Forth 4.45 2021-04-17

: foo1 ." foo" ; immediate ok
aka foo1 foo2 ok
: bla1 foo1 ; foo ok
bla1 ok
: bla2 foo2 ; foo ok
bla2 ok

On 7/06/2021 06:03, Heinrich Hohl wrote:
> On Sunday, June 6, 2021 at 7:55:01 PM UTC+2, Anton Ertl wrote:
>> Starting with a fresh SwiftForth 3.11, I type in:
>> : foo1 ." foo" ;
>> synonym foo2 foo1
>> defer bar immediate
>> ' foo1 is bar
>> : bla1 bar ; \ prints "foo"
>> bla1 \ prints nothing
>> ' foo2 is bar
>> : bla2 bar ; \ prints "foo"
>> bla2 \ prints nothing
>
> Hello Anton,
>
> thank you for the explanations. These are simple but good examples.
>
> Now I see the shortcomings in SwiftForth's SYNONYM.

Briefly tested but will leave it to others to validate.
There may be a reason why SwiftForth's SYNONYM was so complicated
but I didn't look that far.

: AKA ( "old" "new" -- ) DEFINED TUCK HUH?
HEADER >CODE ,JMP 0> IF IMMEDIATE THEN ;

: SYNONYM ( "new" "old" ) HEADER +SMUDGE DEFINED
TUCK HUH? -SMUDGE >CODE ,JMP 0> IF IMMEDIATE THEN ;

Note: xt of the alias will be different from the original.

dxforth <dxforth@gmail.com> writes:
>There may be a reason why SwiftForth's SYNONYM was so complicated
>but I didn't look that far.

My guess is that the broken Forth-2012 reference implementation led
the SwiftForth implementors astray. See also
<https://forth-standard.org/standard/tools/SYNONYM#reply-554>

>: SYNONYM ( "new" "old" ) HEADER +SMUDGE DEFINED
> TUCK HUH? -SMUDGE >CODE ,JMP 0> IF IMMEDIATE THEN ;

Looks correct to me.

I have sent it (with credits) as s followon to my bug report to Forth,
Inc.

- 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 2021: https://euro.theforth.net/2021

On Monday, June 7, 2021 at 6:44:02 AM UTC+2, dxforth wrote:
> OTOH their AKA doesn't promote immediacy:

Yes, I also noticed this. But I was not sure if this is a feature or a bug.
In case of immediate words I would have used:

: foo1 ." foo" ; immediate
aka foo1 foo2 immediate

That is, I would have set the precedence bit manually. Of course, this is only
possible if you are aware of the fact that the original word is immediate.

> Briefly tested but will leave it to others to validate.
>
> : AKA ( "old" "new" -- ) DEFINED TUCK HUH?
> HEADER >CODE ,JMP 0> IF IMMEDIATE THEN ;
>
> : SYNONYM ( "new" "old" ) HEADER +SMUDGE DEFINED
> TUCK HUH? -SMUDGE >CODE ,JMP 0> IF IMMEDIATE THEN ;
>
> Note: xt of the alias will be different from the original.

Looks good to me. My plan for today was to extend AKA so that immediate words
are handled automatically. Your definitions work properly and you saved me some time.
Thank you.

I could not see the need for temporary smudging right away, but smudging seems
to be needed to prevent a user error:

Assuming that "yyy" has never been defined, "SYNONYM yyy yyy" would not
trigger an error message. The newly defined "yyy" would just contain a jump
to itself, meaning that executing the word would result in an endless loop.

Your new definition of SYNONYM for SwiftForth looks good to me. It is more
complicated than AKA, but the core of the word is still "HEADER xt >CODE ,JMP".
All the other words are just used to prevent errors and they are executed during
compilation only.

This version of SYNONYM adds the overhead of one JMP instruction to
every synonym, in comparison with the original word. This is ok for me.
In words that are not time-critical (e.g. WORDS), this overhead is irrelevant.
If words are time-critical (e.g. + or INVERT), I would not use SYNONYM
anyway but rather define the new word based on the original word's code.

Henry

On Monday, June 7, 2021 at 6:44:02 AM UTC+2, dxforth wrote:
> There may be a reason why SwiftForth's SYNONYM was so complicated
> but I didn't look that far.

I think I can answer that. For this you need to switch off the optimizer.

-OPTIMIZER

AKA + A+
SYNONYM S+ +

: TEST 5 + ;
: ATEST 5 A+ ;
: STEST 5 S+ ;

In SwiftForth, "+" is an inline code definition. Use SEE to investigate what was
compiled into TEST, ATEST and STEST.

You see that the inline code of "+" has been expanded and compiled into TEST.
This gives best speed.
ATEST has compiled a call to "+", meaning that overhead has been added.
STEST has exactly the same code as TEST.

Without the optimizer, SYNONYM will compile better code than AKA
if the synonym refers to an word that was defined using ICODE.
In case of ordinary CODE definitions (e.g. "<") or colon definitions (e.g. WORDS),
there is no difference between AKA and SYNONYM.

Now switch on the optimizer and repeat the test. In this case, the optimizer
produces the same code in all three cases, TEST, ATEST and STEST. No matter
whether the original words was defined using ICODE, CODE or colon.

Taking the SwiftForth optimizer into consideration, it is no longer true that
a synonym based on JMP always introduces overhead. For me this is one more
reason to prefer the definition presented by dxforth over the current version
of SYNONYM in SwiftForth that creates immediate words.

Henry

Heinrich Hohl <hheinrich.hohl@gmail.com> writes:
>I could not see the need for temporary smudging right away, but smudging seems
>to be needed to prevent a user error:
>
>Assuming that "yyy" has never been defined, "SYNONYM yyy yyy" would not
>trigger an error message. The newly defined "yyy" would just contain a jump
>to itself, meaning that executing the word would result in an endless loop.

The +SMUDGE and -SMUDGE implement the following parts of the SYNONYM
specification:

|Newname may be the same as oldname; when looking up oldname, newname
|shall not be found.

So this is not just about detecting user error.

- 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 2021: https://euro.theforth.net/2021

On Monday, June 7, 2021 at 6:07:35 PM UTC+2, Anton Ertl wrote:
> The +SMUDGE and -SMUDGE implement the following parts of the SYNONYM
> specification:
>
> |Newname may be the same as oldname; when looking up oldname, newname
> |shall not be found.
>
> So this is not just about detecting user error.
> - anton
> --

Yes, I see. Without smudge, identical names would lead to recursion. Execution of
the synonym would cause an endless loop.

Henry

On 7/06/2021 22:13, Heinrich Hohl wrote:
> On Monday, June 7, 2021 at 6:44:02 AM UTC+2, dxforth wrote:
>> OTOH their AKA doesn't promote immediacy:
>
> Yes, I also noticed this. But I was not sure if this is a feature or a bug.

For most cases (non-immediate words) it's neither - perhaps why it
never became an issue. The 'feature' would be turning an immediate
word into a non-immediate alias - an unusual scenario. IMO the more
like explanation is AKA came from polyForth where space was a premium.
Handling immediate words explicitly wasn't seen as a burden.

On 2021-05-17 18:36, Anton Ertl wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
[...]

>> "POSTPONE" can be implemented according the specification in any system,
>> as I shown earlier: https://git.io/J30D6
>
> At a quick glance this looks like a variant of the code I discussed in
> <2019Jul18.134124@mips.complang.tuwien.ac.at>

Yes, but I didn't receive your answer to my latest arguments in that
thread, see at:

news:qi6con$1bdk$1@gioia.aioe.org on 2019-08-04
- Subject: Re: Semantics rethinking
- The raw message:
https://groups.google.com/forum/message/raw?msg=comp.lang.forth/vrq2f2XXy1Q/tiuq7hJTFgAJ
- The message in the thread:
https://groups.google.com/g/comp.lang.forth/c/vrq2f2XXy1Q/m/tiuq7hJTFgAJ

> which fails these tests:
> : foo state @ . ; immediate
> : foo1 postpone foo ;
> foo1 \ should print 0 (the current state)

It should not, since it's inconsistent.
So if not relying on a99-027 it shall print a nonzero.

Having this definition for "foo1" and regardless how "foo" is defined, I
believe it's an inconsistency if you allow to perform ES(foo1) in
interpretation state and doesn't hold the equivalence of the phrase:
[ x{ foo1 }
and the phrase:
x{ foo }
in compilation state, where "x{" is defined as:
: x{ '}' parse evaluate ] ; immediate

Your interpretation for the "compilation semantics" notion has this
inconsistency as a consequence, and so this inconsistency is allowed by
your interpretation.

But a99-027 excludes this inconsistency since it disallows to perform
ES(foo1) in interpretation state.

My point is that if we allow ES(foo1) in interpretation state, we should
be consistent and hold the above equivalence.

In my PoC https://git.io/J30D6 this equivalence is held, and foo1 prints
a nonzero.

> : x] ] ; immediate
> : y] postpone x] ;
> : bar [ 2 2 + y] literal . ;
> bar \ should print 4

In my implementation it prints 4 (it can be tested in Gforth too).
But I'm inclined to the idea that it is not obligatory, and moreover,
this code might raise an error.

The compilation semantics for "x]" are to do nothing — since neither
standard program can detect any side effect when "x]" is encountered by
the Forth text interpreter in compilation state. That is, the
compilation semantics for "x]" produce zero side effects.

It means that "postpone x]" should appends semantically nothing to the
current definition. Then, the execution semantics of "y]" are to do
nothing. Then, the interpretation semantics for "y]" are to do nothing too.

And then, the code:

: bar [ 2 2 + y] literal . ;

is ambiguous. Due to "y]" does nothing, "literal" is encountered in
interpretation state, and the interpretation semantics for "literal" are
undefined.

Due to an ambiguous condition, the standard requires nothing from this
code. Hence, the standard doesn't require that "bar" should print 4.

--
Ruvim