Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

"Your butt is mine." -- Michael Jackson, Bad


devel / comp.lang.forth / Re: Poll: equivalence for postpone expression

SubjectAuthor
* Poll: equivalence for postpone expressionRuvim
+* Re: Poll: equivalence for postpone expressionP Falth
|+* Re: Poll: equivalence for postpone expressionRuvim
||`* Re: Poll: equivalence for postpone expressionP Falth
|| `* Re: Poll: equivalence for postpone expressionRuvim
||  `* Re: Poll: equivalence for postpone expressionP Falth
||   `* Re: Poll: equivalence for postpone expressionRuvim
||    `* Re: Poll: equivalence for postpone expressionP Falth
||     `* Re: Poll: equivalence for postpone expressionRuvim
||      `* Re: Poll: equivalence for postpone expressionP Falth
||       `- Re: Poll: equivalence for postpone expressionRuvim
|`* Re: Poll: equivalence for postpone expressionGerry Jackson
| `* Re: Poll: equivalence for postpone expressiondxforth
|  `* Re: Poll: equivalence for postpone expressionGerry Jackson
|   +* Re: Poll: equivalence for postpone expressiondxforth
|   |`* Re: Poll: equivalence for postpone expressionGerry Jackson
|   | `- Re: Poll: equivalence for postpone expressiondxforth
|   `* Re: Poll: equivalence for postpone expressionRuvim
|    `* Re: Poll: equivalence for postpone expressionGerry Jackson
|     `- Re: Poll: equivalence for postpone expressionRuvim
+* Re: Poll: equivalence for postpone expressionnone
|`* Re: Poll: equivalence for postpone expressionRuvim
| `* Re: Poll: equivalence for postpone expressionPaul Rubin
|  +- Re: Poll: equivalence for postpone expressionRuvim
|  `- Re: Poll: equivalence for postpone expressionnone
+* Re: Poll: equivalence for postpone expressiondxforth
|+* Re: Poll: equivalence for postpone expressionAnton Ertl
||`* Re: Poll: equivalence for postpone expressiondxforth
|| +* Re: Poll: equivalence for postpone expressionKrishna Myneni
|| |`- Re: Poll: equivalence for postpone expressiondxforth
|| `- Re: Poll: equivalence for postpone expressiondxforth
|`* Re: Poll: equivalence for postpone expressionRuvim
| `- Re: Poll: equivalence for postpone expressiondxforth
+* Re: Poll: equivalence for postpone expressionKrishna Myneni
|+* Re: Poll: equivalence for postpone expressionRuvim
||`* Re: Poll: equivalence for postpone expressionKrishna Myneni
|| +- Re: Poll: equivalence for postpone expressionKrishna Myneni
|| `* Re: Poll: equivalence for postpone expressionRuvim
||  `* Re: Poll: equivalence for postpone expressionKrishna Myneni
||   `- Re: Poll: equivalence for postpone expressionRuvim
|`- Re: Poll: equivalence for postpone expressionS Jack
+* Re: Poll: equivalence for postpone expressionKrishna Myneni
|`* Re: Poll: equivalence for postpone expressionRuvim
| `* Re: Poll: equivalence for postpone expressionKrishna Myneni
|  `* Re: Poll: equivalence for postpone expressionRuvim
|   `* Re: Poll: equivalence for postpone expressionP Falth
|    `- Re: Poll: equivalence for postpone expressionRuvim
`* Re: Poll: equivalence for postpone expressionRuvim
 `* Re: Poll: equivalence for postpone expressiondxforth
  `* Re: Poll: equivalence for postpone expressionRuvim
   `* Re: Poll: equivalence for postpone expressiondxforth
    `* Re: Poll: equivalence for postpone expressionRuvim
     +* Re: Poll: equivalence for postpone expressionP Falth
     |`* Re: Poll: equivalence for postpone expressionRuvim
     | `* Re: Poll: equivalence for postpone expressiondxforth
     |  `* Re: Poll: equivalence for postpone expressionRuvim
     |   +* Re: Poll: equivalence for postpone expressionP Falth
     |   |`* Re: Poll: equivalence for postpone expressionRuvim
     |   | `* Re: Poll: equivalence for postpone expressionP Falth
     |   |  `- Re: Poll: equivalence for postpone expressionRuvim
     |   `- Re: Poll: equivalence for postpone expressiondxforth
     `- Re: Poll: equivalence for postpone expressiondxforth

Pages:123
Re: Poll: equivalence for postpone expression

<sb644g$igq$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=13747&group=comp.lang.forth#13747

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!aioe.org!xrnZ5uanw3pSzK+Ytx4Jfg.user.gioia.aioe.org.POSTED!not-for-mail
From: dxfo...@gmail.com (dxforth)
Newsgroups: comp.lang.forth
Subject: Re: Poll: equivalence for postpone expression
Date: Sat, 26 Jun 2021 12:41:23 +1000
Organization: Aioe.org NNTP Server
Lines: 15
Message-ID: <sb644g$igq$1@gioia.aioe.org>
References: <salij8$m2m$1@dont-email.me> <sb24c1$jr$2@dont-email.me>
<sb325d$91d$1@gioia.aioe.org> <sb4eg2$4bm$1@dont-email.me>
<sb4jon$pdp$1@gioia.aioe.org> <sb4l9a$49n$1@dont-email.me>
<f9be9772-c4fd-4257-8a61-e0816094b8fbn@googlegroups.com>
<sb5eio$cvm$1@dont-email.me>
NNTP-Posting-Host: xrnZ5uanw3pSzK+Ytx4Jfg.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.11.0
Content-Language: en-GB
X-Notice: Filtered by postfilter v. 0.9.2
 by: dxforth - Sat, 26 Jun 2021 02:41 UTC

On 26/06/2021 06:33, Ruvim wrote:
>>> On 2021-06-25 15:55, dxforth wrote:
>>
>> : ', ' ] compile, postpone [ ; ok
>> : foo [ ', >r ', * ', r> ', / ] ; FOO redefined ok
>> : foo1 >r * r> / ; FOO1 redefined ok
> ...
> It's obvious, this "foo" is not standard. A standard program cannot tick
> ">r". It's a system specific definition, namely it's compliant with only
> the systems where ">r" and "r>" are implemented as ordinary words. lxf
> is not such a system.

Good call. Even I didn't spot that believing what I wrote was 'standard'.
And it worked on several systems I tried. If anything it demonstrates
the pitfalls of doing stuff in interpret mode.

Re: Poll: equivalence for postpone expression

<sb9d0d$vaq$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=13754&group=comp.lang.forth#13754

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ruvim.pi...@gmail.com (Ruvim)
Newsgroups: comp.lang.forth
Subject: Re: Poll: equivalence for postpone expression
Date: Sun, 27 Jun 2021 11:31:07 +0300
Organization: A noiseless patient Spider
Lines: 63
Message-ID: <sb9d0d$vaq$1@dont-email.me>
References: <salij8$m2m$1@dont-email.me> <sb24c1$jr$2@dont-email.me>
<sb325d$91d$1@gioia.aioe.org> <sb4eg2$4bm$1@dont-email.me>
<sb4jon$pdp$1@gioia.aioe.org> <sb4l9a$49n$1@dont-email.me>
<f9be9772-c4fd-4257-8a61-e0816094b8fbn@googlegroups.com>
<sb5eio$cvm$1@dont-email.me> <sb644g$igq$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 27 Jun 2021 08:31:09 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="441a8be7e1605b9fdb166813e1395894";
logging-data="32090"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/loClPs6DHyoVILNCeCPuq"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.11.0
Cancel-Lock: sha1:HJP2eHw6Qdx6fqCECSwYrNfZMGk=
In-Reply-To: <sb644g$igq$1@gioia.aioe.org>
Content-Language: en-US
X-Mozilla-News-Host: news://nntp.aioe.org
 by: Ruvim - Sun, 27 Jun 2021 08:31 UTC

On 2021-06-26 05:41, dxforth wrote:
> On 26/06/2021 06:33, Ruvim wrote:
>>>> On 2021-06-25 15:55, dxforth wrote:
>>>
>>> : ',  ' ] compile, postpone [ ;  ok
>>> : foo  [ ', >r  ', *  ', r>  ', / ] ; FOO redefined  ok
>>> : foo1  >r * r> / ; FOO1 redefined  ok
>> ... It's obvious, this "foo" is not standard. A standard program
>> cannot tick
>> ">r". It's a system specific definition, namely it's compliant with only
>> the systems where ">r" and "r>" are implemented as ordinary words. lxf
>> is not such a system.
>
> Good call.  Even I didn't spot that believing what I wrote was 'standard'.
> And it worked on several systems I tried.  If anything it demonstrates
> the pitfalls of doing stuff in interpret mode.

It demonstrates the pitfalls of non standard code.

Your "'," word can be implemented via a full-fledged "find". Taking into
account that some dual-xt systems don't provide full-fledged "find", we
can try to use "find-name" and "name>compile" instead.

A portable definition for "'," is following.

[undefined] 2nip [if] : 2nip ( d2 d1 -- d1 ) 2swap 2drop ; [then]

: ?nf ( x|0 -- ) if exit then -13 throw ;
: ?ni ( x|0 -- ) if exit then -14 throw ;

[defined] find-name [defined] name>compile and [if]
: evaluate-word ( i*x sd-name -- j*x )
find-name dup ?nf
state @ if name>compile else name>interpret dup ?ni then execute
;
[else]
: find-sem ( sd-name -- xt flag-special true | sd-name false )
2dup dup pad c! pad 1+ swap move pad ( sd -- sd c-addr )
find dup if 2nip 1 = true exit then nip
;
: evaluate-word ( i*x sd-name -- j*x )
find-sem ?nf state @ 0= or if execute exit then compile,
;
[then]

: ', ( i*x "ccc" -- j*x ) ] parse-name evaluate-word postpone [ ;

\ test

: foo [ ', >r ', * ', r> ', / ] ;
: foo1 >r * r> / ;

t{ 3 10 6 foo -> 3 10 6 foo1 }t

--
Ruvim

Re: Poll: equivalence for postpone expression

<6e56d6ef-2959-4d45-87a3-3b9fdf8a8c0en@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=13756&group=comp.lang.forth#13756

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:a0c:c345:: with SMTP id j5mr4806557qvi.26.1624788933577;
Sun, 27 Jun 2021 03:15:33 -0700 (PDT)
X-Received: by 2002:ad4:5143:: with SMTP id g3mr13337631qvq.0.1624788933323;
Sun, 27 Jun 2021 03:15:33 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.mixmin.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Sun, 27 Jun 2021 03:15:33 -0700 (PDT)
In-Reply-To: <sb9d0d$vaq$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2a01:2000:2001:e78c:b0ca:2400:9bfb:f5;
posting-account=ryzhhAoAAAAIqf1uqmG9E4uP1Bagd-k2
NNTP-Posting-Host: 2a01:2000:2001:e78c:b0ca:2400:9bfb:f5
References: <salij8$m2m$1@dont-email.me> <sb24c1$jr$2@dont-email.me>
<sb325d$91d$1@gioia.aioe.org> <sb4eg2$4bm$1@dont-email.me>
<sb4jon$pdp$1@gioia.aioe.org> <sb4l9a$49n$1@dont-email.me>
<f9be9772-c4fd-4257-8a61-e0816094b8fbn@googlegroups.com> <sb5eio$cvm$1@dont-email.me>
<sb644g$igq$1@gioia.aioe.org> <sb9d0d$vaq$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <6e56d6ef-2959-4d45-87a3-3b9fdf8a8c0en@googlegroups.com>
Subject: Re: Poll: equivalence for postpone expression
From: peter.m....@gmail.com (P Falth)
Injection-Date: Sun, 27 Jun 2021 10:15:33 +0000
Content-Type: text/plain; charset="UTF-8"
 by: P Falth - Sun, 27 Jun 2021 10:15 UTC

On Sunday, 27 June 2021 at 10:31:11 UTC+2, Ruvim wrote:
> On 2021-06-26 05:41, dxforth wrote:
> > On 26/06/2021 06:33, Ruvim wrote:
> >>>> On 2021-06-25 15:55, dxforth wrote:
> >>>
> >>> : ', ' ] compile, postpone [ ; ok
> >>> : foo [ ', >r ', * ', r> ', / ] ; FOO redefined ok
> >>> : foo1 >r * r> / ; FOO1 redefined ok
> >> ... It's obvious, this "foo" is not standard. A standard program
> >> cannot tick
> >> ">r". It's a system specific definition, namely it's compliant with only
> >> the systems where ">r" and "r>" are implemented as ordinary words. lxf
> >> is not such a system.
> >
> > Good call. Even I didn't spot that believing what I wrote was 'standard'.
> > And it worked on several systems I tried. If anything it demonstrates
> > the pitfalls of doing stuff in interpret mode.
> It demonstrates the pitfalls of non standard code.
>
> Your "'," word can be implemented via a full-fledged "find". Taking into
> account that some dual-xt systems don't provide full-fledged "find", we
> can try to use "find-name" and "name>compile" instead.
>
> A portable definition for "'," is following.
>
>
> [undefined] 2nip [if] : 2nip ( d2 d1 -- d1 ) 2swap 2drop ; [then]
>
> : ?nf ( x|0 -- ) if exit then -13 throw ;
> : ?ni ( x|0 -- ) if exit then -14 throw ;
>
>
> [defined] find-name [defined] name>compile and [if]
> : evaluate-word ( i*x sd-name -- j*x )
> find-name dup ?nf
> state @ if name>compile else name>interpret dup ?ni then execute
> ;
> [else]
> : find-sem ( sd-name -- xt flag-special true | sd-name false )
> 2dup dup pad c! pad 1+ swap move pad ( sd -- sd c-addr )
> find dup if 2nip 1 = true exit then nip
> ;
> : evaluate-word ( i*x sd-name -- j*x )
> find-sem ?nf state @ 0= or if execute exit then compile,
> ;
> [then]
>
>
> : ', ( i*x "ccc" -- j*x ) ] parse-name evaluate-word postpone [ ;

I did
: ', parse-name find-name name>compile execute ;

Missing error checking and not setting the execution under compile state

But even better with recognizers ( my own version of them)

: ', parse-name recognize cell+ @ execute ;

This also support numbers and locals!

I can now write

code foo ', if ', ." true" ', else ', ." false" ', then ', ;

instead of

: foo if ." true" else ." false" then ;

Honestly I still think this is better!

BR
Peter

> \ test
> : foo [ ', >r ', * ', r> ', / ] ;
> : foo1 >r * r> / ;
> t{ 3 10 6 foo -> 3 10 6 foo1 }t
>
>
>
>
> --
> Ruvim

Re: Poll: equivalence for postpone expression

<sb9ns2$1460$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=13757&group=comp.lang.forth#13757

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!aioe.org!xrnZ5uanw3pSzK+Ytx4Jfg.user.gioia.aioe.org.POSTED!not-for-mail
From: dxfo...@gmail.com (dxforth)
Newsgroups: comp.lang.forth
Subject: Re: Poll: equivalence for postpone expression
Date: Sun, 27 Jun 2021 21:36:34 +1000
Organization: Aioe.org NNTP Server
Lines: 21
Message-ID: <sb9ns2$1460$1@gioia.aioe.org>
References: <salij8$m2m$1@dont-email.me> <sb24c1$jr$2@dont-email.me>
<sb325d$91d$1@gioia.aioe.org> <sb4eg2$4bm$1@dont-email.me>
<sb4jon$pdp$1@gioia.aioe.org> <sb4l9a$49n$1@dont-email.me>
<f9be9772-c4fd-4257-8a61-e0816094b8fbn@googlegroups.com>
<sb5eio$cvm$1@dont-email.me> <sb644g$igq$1@gioia.aioe.org>
<sb9d0d$vaq$1@dont-email.me>
NNTP-Posting-Host: xrnZ5uanw3pSzK+Ytx4Jfg.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.11.0
X-Notice: Filtered by postfilter v. 0.9.2
Content-Language: en-GB
 by: dxforth - Sun, 27 Jun 2021 11:36 UTC

On 27/06/2021 18:31, Ruvim wrote:
> On 2021-06-26 05:41, dxforth wrote:
>> On 26/06/2021 06:33, Ruvim wrote:
>>>>> On 2021-06-25 15:55, dxforth wrote:
>>>>
>>>> : ',  ' ] compile, postpone [ ;  ok
>>>> : foo  [ ', >r  ', *  ', r>  ', / ] ; FOO redefined  ok
>>>> : foo1  >r * r> / ; FOO1 redefined  ok
>>> ... It's obvious, this "foo" is not standard. A standard program
>>> cannot tick
>>> ">r". It's a system specific definition, namely it's compliant with only
>>> the systems where ">r" and "r>" are implemented as ordinary words. lxf
>>> is not such a system.
>>
>> Good call.  Even I didn't spot that believing what I wrote was 'standard'.
>> And it worked on several systems I tried.  If anything it demonstrates
>> the pitfalls of doing stuff in interpret mode.
>
> It demonstrates the pitfalls of non standard code.

It demonstrates the pitfalls of writing standard code beyond the trivial.

Re: Poll: equivalence for postpone expression

<sb9puv$7tq$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=13758&group=comp.lang.forth#13758

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ruvim.pi...@gmail.com (Ruvim)
Newsgroups: comp.lang.forth
Subject: Re: Poll: equivalence for postpone expression
Date: Sun, 27 Jun 2021 15:12:13 +0300
Organization: A noiseless patient Spider
Lines: 82
Message-ID: <sb9puv$7tq$1@dont-email.me>
References: <salij8$m2m$1@dont-email.me> <sb24c1$jr$2@dont-email.me>
<sb325d$91d$1@gioia.aioe.org> <sb4eg2$4bm$1@dont-email.me>
<sb4jon$pdp$1@gioia.aioe.org> <sb4l9a$49n$1@dont-email.me>
<f9be9772-c4fd-4257-8a61-e0816094b8fbn@googlegroups.com>
<sb5eio$cvm$1@dont-email.me> <sb644g$igq$1@gioia.aioe.org>
<sb9d0d$vaq$1@dont-email.me>
<6e56d6ef-2959-4d45-87a3-3b9fdf8a8c0en@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 27 Jun 2021 12:12:15 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="441a8be7e1605b9fdb166813e1395894";
logging-data="8122"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+fRH30pERRDKmK5iUmEM9p"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.11.0
Cancel-Lock: sha1:ZO5xYigV4N9w8EOkOwU02KNOlb0=
In-Reply-To: <6e56d6ef-2959-4d45-87a3-3b9fdf8a8c0en@googlegroups.com>
Content-Language: en-US
 by: Ruvim - Sun, 27 Jun 2021 12:12 UTC

On 2021-06-27 13:15, P Falth wrote:
> On Sunday, 27 June 2021 at 10:31:11 UTC+2, Ruvim wrote:
>> On 2021-06-26 05:41, dxforth wrote:
[...]
>>> Good call. Even I didn't spot that believing what I wrote was 'standard'.
>>> And it worked on several systems I tried. If anything it demonstrates
>>> the pitfalls of doing stuff in interpret mode.
>> It demonstrates the pitfalls of non standard code.
>>
>> Your "'," word can be implemented via a full-fledged "find". Taking into
>> account that some dual-xt systems don't provide full-fledged "find", we
>> can try to use "find-name" and "name>compile" instead.
>>
>> A portable definition for "'," is following.
>>
>>
>> [undefined] 2nip [if] : 2nip ( d2 d1 -- d1 ) 2swap 2drop ; [then]
>>
>> : ?nf ( x|0 -- ) if exit then -13 throw ;
>> : ?ni ( x|0 -- ) if exit then -14 throw ;
>>
>>
>> [defined] find-name [defined] name>compile and [if]
>> : evaluate-word ( i*x sd-name -- j*x )
>> find-name dup ?nf
>> state @ if name>compile else name>interpret dup ?ni then execute
>> ;
>> [else]
>> : find-sem ( sd-name -- xt flag-special true | sd-name false )
>> 2dup dup pad c! pad 1+ swap move pad ( sd -- sd c-addr )
>> find dup if 2nip 1 = true exit then nip
>> ;
>> : evaluate-word ( i*x sd-name -- j*x )
>> find-sem ?nf state @ 0= or if execute exit then compile,
>> ;
>> [then]
>>
>>
>> : ', ( i*x "ccc" -- j*x ) ] parse-name evaluate-word postpone [ ;
>
> I did
> : ', parse-name find-name name>compile execute ;
>
> Missing error checking
> and not setting the execution under compile state

What xt "name>compile" returns for immediate words?

If it's just the xt of "execute", then this "'," will work incorrectly
for dual-semantics immediate words. It can work, if the xt is for
something like "execute-compiling".

> But even better with recognizers ( my own version of them)
>
> : ', parse-name recognize cell+ @ execute ;
>
> This also support numbers and locals!
>
> I can now write
>
> code foo ', if ', ." true" ', else ', ." false" ', then ', ;

With recognizers, it's also possible to have a recognizer for "ccc," or
",ccc" so this line can look as:

code foo ,if ,." true" ,else ,." false" ,then ,;

> instead of
>
> : foo if ." true" else ." false" then ;
>
> Honestly I still think this is better!

Nobody suggests to use the former instead of the latter in all the
cases. But it doesn't mean that the former should be outlawed.

--
Ruvim

Re: Poll: equivalence for postpone expression

<1437a3de-92cd-4a47-b833-eed261255534n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=13762&group=comp.lang.forth#13762

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:a05:622a:149:: with SMTP id v9mr18177786qtw.144.1624806688420;
Sun, 27 Jun 2021 08:11:28 -0700 (PDT)
X-Received: by 2002:ad4:5143:: with SMTP id g3mr14413541qvq.0.1624806688235;
Sun, 27 Jun 2021 08:11:28 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Sun, 27 Jun 2021 08:11:28 -0700 (PDT)
In-Reply-To: <sb9puv$7tq$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2a01:2000:2001:e78c:7926:612a:5e19:ebc3;
posting-account=ryzhhAoAAAAIqf1uqmG9E4uP1Bagd-k2
NNTP-Posting-Host: 2a01:2000:2001:e78c:7926:612a:5e19:ebc3
References: <salij8$m2m$1@dont-email.me> <sb24c1$jr$2@dont-email.me>
<sb325d$91d$1@gioia.aioe.org> <sb4eg2$4bm$1@dont-email.me>
<sb4jon$pdp$1@gioia.aioe.org> <sb4l9a$49n$1@dont-email.me>
<f9be9772-c4fd-4257-8a61-e0816094b8fbn@googlegroups.com> <sb5eio$cvm$1@dont-email.me>
<sb644g$igq$1@gioia.aioe.org> <sb9d0d$vaq$1@dont-email.me>
<6e56d6ef-2959-4d45-87a3-3b9fdf8a8c0en@googlegroups.com> <sb9puv$7tq$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <1437a3de-92cd-4a47-b833-eed261255534n@googlegroups.com>
Subject: Re: Poll: equivalence for postpone expression
From: peter.m....@gmail.com (P Falth)
Injection-Date: Sun, 27 Jun 2021 15:11:28 +0000
Content-Type: text/plain; charset="UTF-8"
 by: P Falth - Sun, 27 Jun 2021 15:11 UTC

On Sunday, 27 June 2021 at 14:12:17 UTC+2, Ruvim wrote:
> On 2021-06-27 13:15, P Falth wrote:
> > On Sunday, 27 June 2021 at 10:31:11 UTC+2, Ruvim wrote:
> >> On 2021-06-26 05:41, dxforth wrote:
> [...]
> >>> Good call. Even I didn't spot that believing what I wrote was 'standard'.
> >>> And it worked on several systems I tried. If anything it demonstrates
> >>> the pitfalls of doing stuff in interpret mode.
> >> It demonstrates the pitfalls of non standard code.
> >>
> >> Your "'," word can be implemented via a full-fledged "find". Taking into
> >> account that some dual-xt systems don't provide full-fledged "find", we
> >> can try to use "find-name" and "name>compile" instead.
> >>
> >> A portable definition for "'," is following.
> >>
> >>
> >> [undefined] 2nip [if] : 2nip ( d2 d1 -- d1 ) 2swap 2drop ; [then]
> >>
> >> : ?nf ( x|0 -- ) if exit then -13 throw ;
> >> : ?ni ( x|0 -- ) if exit then -14 throw ;
> >>
> >>
> >> [defined] find-name [defined] name>compile and [if]
> >> : evaluate-word ( i*x sd-name -- j*x )
> >> find-name dup ?nf
> >> state @ if name>compile else name>interpret dup ?ni then execute
> >> ;
> >> [else]
> >> : find-sem ( sd-name -- xt flag-special true | sd-name false )
> >> 2dup dup pad c! pad 1+ swap move pad ( sd -- sd c-addr )
> >> find dup if 2nip 1 = true exit then nip
> >> ;
> >> : evaluate-word ( i*x sd-name -- j*x )
> >> find-sem ?nf state @ 0= or if execute exit then compile,
> >> ;
> >> [then]
> >>
> >>
> >> : ', ( i*x "ccc" -- j*x ) ] parse-name evaluate-word postpone [ ;
> >
> > I did
> > : ', parse-name find-name name>compile execute ;
> >
> > Missing error checking
> > and not setting the execution under compile state
> What xt "name>compile" returns for immediate words?
>
> If it's just the xt of "execute", then this "'," will work incorrectly
> for dual-semantics immediate words. It can work, if the xt is for
> something like "execute-compiling".

It is not the xt of execute. But it will have the problem anyway.
That is for a state smart immediate word the branch for
state = 0 will be taken.

But is this really a problem? If you compile while interpreting
(state=0) is that not what you expect to happen?
Otherwise you would have compiled while compiling!

> > But even better with recognizers ( my own version of them)
> >
> > : ', parse-name recognize cell+ @ execute ;
> >
> > This also support numbers and locals!
> >
> > I can now write
> >
> > code foo ', if ', ." true" ', else ', ." false" ', then ', ;
> With recognizers, it's also possible to have a recognizer for "ccc," or
> ",ccc" so this line can look as:
>
> code foo ,if ,." true" ,else ,." false" ,then ,;
> > instead of
> >
> > : foo if ." true" else ." false" then ;
> >
> > Honestly I still think this is better!
> Nobody suggests to use the former instead of the latter in all the
> cases. But it doesn't mean that the former should be outlawed.

But if you want this to work in a consistent way you need to specify
execution semantics for all words without it. Good luck with that!

Maybe also for the cases of interpretation inside and outside of a
started definition.

Peter

> --
> Ruvim

Re: Poll: equivalence for postpone expression

<sbaabn$ld9$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=13765&group=comp.lang.forth#13765

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ruvim.pi...@gmail.com (Ruvim)
Newsgroups: comp.lang.forth
Subject: Re: Poll: equivalence for postpone expression
Date: Sun, 27 Jun 2021 19:52:05 +0300
Organization: A noiseless patient Spider
Lines: 130
Message-ID: <sbaabn$ld9$1@dont-email.me>
References: <salij8$m2m$1@dont-email.me> <sb24c1$jr$2@dont-email.me>
<sb325d$91d$1@gioia.aioe.org> <sb4eg2$4bm$1@dont-email.me>
<sb4jon$pdp$1@gioia.aioe.org> <sb4l9a$49n$1@dont-email.me>
<f9be9772-c4fd-4257-8a61-e0816094b8fbn@googlegroups.com>
<sb5eio$cvm$1@dont-email.me> <sb644g$igq$1@gioia.aioe.org>
<sb9d0d$vaq$1@dont-email.me>
<6e56d6ef-2959-4d45-87a3-3b9fdf8a8c0en@googlegroups.com>
<sb9puv$7tq$1@dont-email.me>
<1437a3de-92cd-4a47-b833-eed261255534n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 27 Jun 2021 16:52:07 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="441a8be7e1605b9fdb166813e1395894";
logging-data="21929"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+6C83PmMCeUHZqzZr+YSgT"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.11.0
Cancel-Lock: sha1:XtgJpiZ1tsOmoNTTcPsKToDDRII=
In-Reply-To: <1437a3de-92cd-4a47-b833-eed261255534n@googlegroups.com>
Content-Language: en-US
 by: Ruvim - Sun, 27 Jun 2021 16:52 UTC

On 2021-06-27 18:11, P Falth wrote:
> On Sunday, 27 June 2021 at 14:12:17 UTC+2, Ruvim wrote:
>> On 2021-06-27 13:15, P Falth wrote:
>>> On Sunday, 27 June 2021 at 10:31:11 UTC+2, Ruvim wrote:
>>>> On 2021-06-26 05:41, dxforth wrote:
>> [...]
>>>>> Good call. Even I didn't spot that believing what I wrote was 'standard'.
>>>>> And it worked on several systems I tried. If anything it demonstrates
>>>>> the pitfalls of doing stuff in interpret mode.
>>>> It demonstrates the pitfalls of non standard code.
>>>>
>>>> Your "'," word can be implemented via a full-fledged "find". Taking into
>>>> account that some dual-xt systems don't provide full-fledged "find", we
>>>> can try to use "find-name" and "name>compile" instead.
>>>>
>>>> A portable definition for "'," is following.
>>>>
>>>>
>>>> [undefined] 2nip [if] : 2nip ( d2 d1 -- d1 ) 2swap 2drop ; [then]
>>>>
>>>> : ?nf ( x|0 -- ) if exit then -13 throw ;
>>>> : ?ni ( x|0 -- ) if exit then -14 throw ;
>>>>
>>>>
>>>> [defined] find-name [defined] name>compile and [if]
>>>> : evaluate-word ( i*x sd-name -- j*x )
>>>> find-name dup ?nf
>>>> state @ if name>compile else name>interpret dup ?ni then execute
>>>> ;
>>>> [else]
>>>> : find-sem ( sd-name -- xt flag-special true | sd-name false )
>>>> 2dup dup pad c! pad 1+ swap move pad ( sd -- sd c-addr )
>>>> find dup if 2nip 1 = true exit then nip
>>>> ;
>>>> : evaluate-word ( i*x sd-name -- j*x )
>>>> find-sem ?nf state @ 0= or if execute exit then compile,
>>>> ;
>>>> [then]
>>>>
>>>>
>>>> : ', ( i*x "ccc" -- j*x ) ] parse-name evaluate-word postpone [ ;
>>>
>>> I did
>>> : ', parse-name find-name name>compile execute ;
>>>
>>> Missing error checking
>>> and not setting the execution under compile state
>> What xt "name>compile" returns for immediate words?
>>
>> If it's just the xt of "execute", then this "'," will work incorrectly
>> for dual-semantics immediate words. It can work, if the xt is for
>> something like "execute-compiling".
>
> It is not the xt of execute. But it will have the problem anyway.
> That is for a state smart immediate word the branch for
> state = 0 will be taken.
>
> But is this really a problem?

It's a problem. Since in my implementation "'," performs the compilation
semantics for any actual argument. In your implementation it performs
the interpretation semantics for some actual arguments.

> If you compile while interpreting
> (state=0) is that not what you expect to happen?

BTW, what I expect is obvious from my implementation =)

The implementation of dxforth for the "'," word was just a PoC (as I can
see), and it's just a parsing alternative to "compile," that works in
interpretation state.

But in the example it was used as if it performs the compilation
semantics for any actual argument. Therefore I showed a correct
implementation for that.

> Otherwise you would have compiled while compiling!

So your point is that for some words you may use "'," to perform their
compilation semantics in interpretation state, but for other words you
may to do it only in compilation state.

This point looks inconsistently to me.

>>> But even better with recognizers ( my own version of them)
>>>
>>> : ', parse-name recognize cell+ @ execute ;
>>>
>>> This also support numbers and locals!
>>>
>>> I can now write
>>>
>>> code foo ', if ', ." true" ', else ', ." false" ', then ', ;
>> With recognizers, it's also possible to have a recognizer for "ccc," or
>> ",ccc" so this line can look as:
>>
>> code foo ,if ,." true" ,else ,." false" ,then ,;
>>> instead of
>>>
>>> : foo if ." true" else ." false" then ;
>>>
>>> Honestly I still think this is better!
>> Nobody suggests to use the former instead of the latter in all the
>> cases. But it doesn't mean that the former should be outlawed.
>
> But if you want this to work in a consistent way you need to specify
> execution semantics for all words without it. Good luck with that!

Compilation (code generation) in interpretation state can be already
implemented in such a way that it works consistently.

If you mean interpretive control flow constructs — it's a totally
different problem.

> Maybe also for the cases of interpretation inside and outside of a
> started definition.

--
Ruvim

Re: Poll: equivalence for postpone expression

<sc4mdb$d7p$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=13873&group=comp.lang.forth#13873

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ruvim.pi...@gmail.com (Ruvim)
Newsgroups: comp.lang.forth
Subject: Re: Poll: equivalence for postpone expression
Date: Wed, 7 Jul 2021 19:57:13 +0300
Organization: A noiseless patient Spider
Lines: 56
Message-ID: <sc4mdb$d7p$1@dont-email.me>
References: <salij8$m2m$1@dont-email.me> <saptvl$jia$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 7 Jul 2021 16:57:15 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="8d7d121264afed0d78569a3b39199934";
logging-data="13561"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+k66Y1njfQ2lsn/h57rA+o"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.11.0
Cancel-Lock: sha1:BWWShkq9yw2UurtCQQ0Ae6dNMqg=
In-Reply-To: <saptvl$jia$1@dont-email.me>
Content-Language: en-US
X-Mozilla-News-Host: news://nntp.aioe.org
 by: Ruvim - Wed, 7 Jul 2021 16:57 UTC

On 2021-06-21 14:42, Krishna Myneni wrote:
> On 6/19/21 3:03 PM, Ruvim wrote:
> ...
>>
>> Let "foo" is a word that doesn't perform any parsing, doesn't access
>> the parse area, and doesn't enter into compilation or interpretation
>> state (i.e., any such behavior is not a part of any semantics for "foo").
>>
>> Let the word "compile-foo" is defined as:
>>    : compile-foo postpone foo ;
>> and it has the same scope as the word "foo".
>>
>>
>>
>> Proposition 1.
>>    The phrase:
>>      [ compile-foo ]
>>    is equivalent to the phrase:
>>        foo
>>    in any such context when the phrase is encountered by the Forth
>>    text interpreter in compilation state.
>>
>>
>
> What is your expectation for use of the phrase "[ COMPILE-FOO ]" inside
> of a definition, when COMPILE-FOO is tagged as an immediate word?
>
> : compile-foo postpone foo ; immediate
>
> In this case the compilation semantics of COMPILE-FOO should be the same
> as its runtime semantics.

In the phrase "[ compile-foo ]" in compilation state, the interpretation
semantics for "compile-foo" are performed, since "[" enters
interpretation state. So in this context it doesn't matter whether
"compile-foo" is immediate or not, and what its compilation semantics.

Regarding the compilation semantics for an immediate word in general.

I assume, by "runtime semantics" you meant "execution semantics".

In some cases, the execution semantics (ES) of an immediate word can be
nonequivalent to its compilation semantics (CS). If you make them
equivalent, you break the equivalence in P1.

NB: Anton Ertl claimed that ES and CS should be equivalent for any
immediate word (and then P1 is false, what I consider as inconsistency).
Don't sure whether he still insist on that.

--
Ruvim

Re: Poll: equivalence for postpone expression

<scc137$dqc$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=13884&group=comp.lang.forth#13884

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: krishna....@ccreweb.org (Krishna Myneni)
Newsgroups: comp.lang.forth
Subject: Re: Poll: equivalence for postpone expression
Date: Sat, 10 Jul 2021 06:42:29 -0500
Organization: A noiseless patient Spider
Lines: 64
Message-ID: <scc137$dqc$1@dont-email.me>
References: <salij8$m2m$1@dont-email.me> <saptvl$jia$1@dont-email.me>
<sc4mdb$d7p$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 10 Jul 2021 11:42:31 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="7ae49fc1a1f85bebda4b42a99145ae30";
logging-data="14156"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19vzk6IqBjr4iRKdFJESl8W"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.11.0
Cancel-Lock: sha1:qOeMDx6TBveCIsKYfl/RIsVZicc=
In-Reply-To: <sc4mdb$d7p$1@dont-email.me>
Content-Language: en-US
 by: Krishna Myneni - Sat, 10 Jul 2021 11:42 UTC

On 7/7/21 11:57 AM, Ruvim wrote:
> On 2021-06-21 14:42, Krishna Myneni wrote:
>> On 6/19/21 3:03 PM, Ruvim wrote:
>> ...
>>>
>>> Let "foo" is a word that doesn't perform any parsing, doesn't access
>>> the parse area, and doesn't enter into compilation or interpretation
>>> state (i.e., any such behavior is not a part of any semantics for
>>> "foo").
>>>
>>> Let the word "compile-foo" is defined as:
>>>    : compile-foo postpone foo ;
>>> and it has the same scope as the word "foo".
>>>
>>>
>>>
>>> Proposition 1.
>>>    The phrase:
>>>      [ compile-foo ]
>>>    is equivalent to the phrase:
>>>        foo
>>>    in any such context when the phrase is encountered by the Forth
>>>    text interpreter in compilation state.
>>>
>>>
>>
>> What is your expectation for use of the phrase "[ COMPILE-FOO ]"
>> inside of a definition, when COMPILE-FOO is tagged as an immediate word?
>>
>> : compile-foo postpone foo ; immediate
>>
>> In this case the compilation semantics of COMPILE-FOO should be the
>> same as its runtime semantics.
>
>
> In the phrase "[ compile-foo ]" in compilation state, the interpretation
> semantics for "compile-foo" are performed, since "[" enters
> interpretation state. So in this context it doesn't matter whether
> "compile-foo" is immediate or not, and what its compilation semantics.
>
>
>
> Regarding the compilation semantics for an immediate word in general.
>
> I assume, by "runtime semantics" you meant "execution semantics".
>

Yes.

> In some cases, the execution semantics (ES) of an immediate word can be
> nonequivalent to its compilation semantics (CS). If you make them
> equivalent, you break the equivalence in P1.
>
> NB: Anton Ertl claimed that ES and CS should be equivalent for any
> immediate word (and then P1 is false, what I consider as inconsistency).
> Don't sure whether he still insist on that.
>

If an IMMEDIATE word does not have ES = CS, how would dual-xt systems
determine the immediacy of a word? Would that not make dual-xt systems
inconsistent with the standard?

Krishna

Re: Poll: equivalence for postpone expression

<schdj8$fdi$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=13901&group=comp.lang.forth#13901

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ruvim.pi...@gmail.com (Ruvim)
Newsgroups: comp.lang.forth
Subject: Re: Poll: equivalence for postpone expression
Date: Mon, 12 Jul 2021 15:46:30 +0300
Organization: A noiseless patient Spider
Lines: 146
Message-ID: <schdj8$fdi$1@dont-email.me>
References: <salij8$m2m$1@dont-email.me> <saptvl$jia$1@dont-email.me>
<sc4mdb$d7p$1@dont-email.me> <scc137$dqc$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 12 Jul 2021 12:46:32 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="becabdcd09a4b21776384f49d0241dbd";
logging-data="15794"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+L6oOuGt7Bf2pyEPlGlgQD"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.11.0
Cancel-Lock: sha1:1C2sskvOGXoBbAWGUfg96Gh5VSs=
In-Reply-To: <scc137$dqc$1@dont-email.me>
Content-Language: en-US
X-Mozilla-News-Host: news://nntp.aioe.org
 by: Ruvim - Mon, 12 Jul 2021 12:46 UTC

On 2021-07-10 14:42, Krishna Myneni wrote:
> On 7/7/21 11:57 AM, Ruvim wrote:
>> On 2021-06-21 14:42, Krishna Myneni wrote:
>>> On 6/19/21 3:03 PM, Ruvim wrote:
>>> ...
>>>>
>>>> Let "foo" is a word that doesn't perform any parsing, doesn't access
>>>> the parse area, and doesn't enter into compilation or interpretation
>>>> state (i.e., any such behavior is not a part of any semantics for
>>>> "foo").
>>>>
>>>> Let the word "compile-foo" is defined as:
>>>>    : compile-foo postpone foo ;
>>>> and it has the same scope as the word "foo".
>>>>
>>>>
>>>>
>>>> Proposition 1.
>>>>    The phrase:
>>>>      [ compile-foo ]
>>>>    is equivalent to the phrase:
>>>>        foo
>>>>    in any such context when the phrase is encountered by the Forth
>>>>    text interpreter in compilation state.
>>>>
>>>>
>>>
>>> What is your expectation for use of the phrase "[ COMPILE-FOO ]"
>>> inside of a definition, when COMPILE-FOO is tagged as an immediate word?
>>>
>>> : compile-foo postpone foo ; immediate
>>>
>>> In this case the compilation semantics of COMPILE-FOO should be the
>>> same as its runtime semantics.
>>
>>
>> In the phrase "[ compile-foo ]" in compilation state, the
>> interpretation semantics for "compile-foo" are performed, since "["
>> enters interpretation state. So in this context it doesn't matter
>> whether "compile-foo" is immediate or not, and what its compilation
>> semantics.
>>
>>
>>
>> Regarding the compilation semantics for an immediate word in general.
>>
>> I assume, by "runtime semantics" you meant "execution semantics".
>>
>
> Yes.
>
>> In some cases, the execution semantics (ES) of an immediate word can
>> be nonequivalent to its compilation semantics (CS). If you make them
>> equivalent, you break the equivalence in P1.
>>
>> NB: Anton Ertl claimed that ES and CS should be equivalent for any
>> immediate word (and then P1 is false, what I consider as
>> inconsistency). Don't sure whether he still insist on that.
>>
>
> If an IMMEDIATE word does not have ES = CS, how would dual-xt systems
> determine the immediacy of a word?

First of all, a system is not obligated to determine whether a word is
immediate (in the standard notion) or not. It's enough to determine
whether a word is ordinary or not [1].

Secondly, I don't see any technical problem with that. Various solutions
can be employed depending on a particular implementation. For example, a
separate flag can be introduced for that.

As I can guess, the question is about a system where two execution
tokens are associated with each name token.

One execution token (xt-int) is *used* to perform the IS for the word,
and another execution token (xt-comp) is *used* to perform the CS for
the word. If a word has default CS, then xt-comp is 0.

For an immediate word xt-int and xt-comp are the same and they both are
equal to the xt-exec that identifies the ES for the word. And it's for
any immediate words. So, to determine whether a word is immediate, the
system compares xt-int and xt-comp.

It's wrong to assume that if CS <> ES, then xt-comp should be unequal to
the xt-exec (they still can be the same in some cases). Since xt-comp
(in general case) doesn't identify CS. It's only *used* to perform CS.

Any execution token (xt) always identifies some ES, and these ES are
performed by applying "EXECUTE" to this xt. It's impossible that an
execution token doesn't identify some ES.

In the same time, some ES can be equivalent (possibly in some
conditions) to the CS for some word, or to the IS for some word [2]. In
such case, by performing these ES (possibly in those conditions) you
perform the corresponding CS or IS.

If the CS are (unconditionally) equivalent to the ES for some word
"foo", then the phrase:
[ xt-comp(foo) EXECUTE ]
is equivalent to the phrase:
[ ' foo EXECUTE ]
that is equivalent to the phrase:
foo
in compilation state, where "xt-comp(foo)" returns xt-comp for the word
"foo" in the considered system implementation.

Hence, if for some word "foo" this phrases are not equivalent, then
CS(foo) are not equivalent to the ES(foo). Obviously, it's a possible
case — the case of an immediate STATE-dependent word. And in the
considered system implementation xt-int = xt-comp in this case.

> Would that not make dual-xt systems
> inconsistent with the standard?

Not in this part. But it depends.

At the moment, if "NAME>COMPILE" returns xt-int(foo) and xt-int(EXECUTE)
for an immediate STATE-dependent word "foo", then it's incorrect, I think.

But the specification for "NAME>COMPILE" can be clarified to relax
implementations. Since at the moment it controverts it's own rationale,
when it says: "xt2 is the xt of EXECUTE (for immediate words)" [3].

[1] See also my proposal for FIND clarification
https://forth-standard.org/proposals/clarify-find-more-classic-approach?hideDiff#reply-682

[2] See also my reasoning concerning relations between xt, ES, CS, IS.
https://forth-standard.org/proposals/reword-the-term-execution-token-?hideDiff#reply-570

[3] https://forth-standard.org/standard/tools/NAMEtoCOMPILE

--
Ruvim

Re: Poll: equivalence for postpone expression

<90895d4d-2ebe-4053-8891-c33fd744307bn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=13902&group=comp.lang.forth#13902

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:a05:622a:407:: with SMTP id n7mr6605436qtx.60.1626096000504;
Mon, 12 Jul 2021 06:20:00 -0700 (PDT)
X-Received: by 2002:a05:620a:21cd:: with SMTP id h13mr2198524qka.375.1626096000161;
Mon, 12 Jul 2021 06:20:00 -0700 (PDT)
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!news.uzoreto.com!peer02.ams4!peer.am4.highwinds-media.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Mon, 12 Jul 2021 06:19:59 -0700 (PDT)
In-Reply-To: <schdj8$fdi$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2a01:2000:2001:4007:61f3:e6:51a1:7631;
posting-account=ryzhhAoAAAAIqf1uqmG9E4uP1Bagd-k2
NNTP-Posting-Host: 2a01:2000:2001:4007:61f3:e6:51a1:7631
References: <salij8$m2m$1@dont-email.me> <saptvl$jia$1@dont-email.me>
<sc4mdb$d7p$1@dont-email.me> <scc137$dqc$1@dont-email.me> <schdj8$fdi$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <90895d4d-2ebe-4053-8891-c33fd744307bn@googlegroups.com>
Subject: Re: Poll: equivalence for postpone expression
From: peter.m....@gmail.com (P Falth)
Injection-Date: Mon, 12 Jul 2021 13:20:00 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 7917
 by: P Falth - Mon, 12 Jul 2021 13:19 UTC

On Monday, 12 July 2021 at 14:46:34 UTC+2, Ruvim wrote:
> On 2021-07-10 14:42, Krishna Myneni wrote:
> > On 7/7/21 11:57 AM, Ruvim wrote:
> >> On 2021-06-21 14:42, Krishna Myneni wrote:
> >>> On 6/19/21 3:03 PM, Ruvim wrote:
> >>> ...
> >>>>
> >>>> Let "foo" is a word that doesn't perform any parsing, doesn't access
> >>>> the parse area, and doesn't enter into compilation or interpretation
> >>>> state (i.e., any such behavior is not a part of any semantics for
> >>>> "foo").
> >>>>
> >>>> Let the word "compile-foo" is defined as:
> >>>> : compile-foo postpone foo ;
> >>>> and it has the same scope as the word "foo".
> >>>>
> >>>>
> >>>>
> >>>> Proposition 1.
> >>>> The phrase:
> >>>> [ compile-foo ]
> >>>> is equivalent to the phrase:
> >>>> foo
> >>>> in any such context when the phrase is encountered by the Forth
> >>>> text interpreter in compilation state.
> >>>>
> >>>>
> >>>
> >>> What is your expectation for use of the phrase "[ COMPILE-FOO ]"
> >>> inside of a definition, when COMPILE-FOO is tagged as an immediate word?
> >>>
> >>> : compile-foo postpone foo ; immediate
> >>>
> >>> In this case the compilation semantics of COMPILE-FOO should be the
> >>> same as its runtime semantics.
> >>
> >>
> >> In the phrase "[ compile-foo ]" in compilation state, the
> >> interpretation semantics for "compile-foo" are performed, since "["
> >> enters interpretation state. So in this context it doesn't matter
> >> whether "compile-foo" is immediate or not, and what its compilation
> >> semantics.
> >>
> >>
> >>
> >> Regarding the compilation semantics for an immediate word in general.
> >>
> >> I assume, by "runtime semantics" you meant "execution semantics".
> >>
> >
> > Yes.
> >
> >> In some cases, the execution semantics (ES) of an immediate word can
> >> be nonequivalent to its compilation semantics (CS). If you make them
> >> equivalent, you break the equivalence in P1.
> >>
> >> NB: Anton Ertl claimed that ES and CS should be equivalent for any
> >> immediate word (and then P1 is false, what I consider as
> >> inconsistency). Don't sure whether he still insist on that.
> >>
> >
> > If an IMMEDIATE word does not have ES = CS, how would dual-xt systems
> > determine the immediacy of a word?
> First of all, a system is not obligated to determine whether a word is
> immediate (in the standard notion) or not. It's enough to determine
> whether a word is ordinary or not [1].
>
> Secondly, I don't see any technical problem with that. Various solutions
> can be employed depending on a particular implementation. For example, a
> separate flag can be introduced for that.
>
>
>
> As I can guess, the question is about a system where two execution
> tokens are associated with each name token.
>
> One execution token (xt-int) is *used* to perform the IS for the word,
> and another execution token (xt-comp) is *used* to perform the CS for
> the word. If a word has default CS, then xt-comp is 0.

Not necessarily. In my system a word with default CS has xt-comp=COMPILE,

> For an immediate word xt-int and xt-comp are the same and they both are
> equal to the xt-exec that identifies the ES for the word. And it's for
> any immediate words. So, to determine whether a word is immediate, the
> system compares xt-int and xt-comp.

Yes this works in my system

> It's wrong to assume that if CS <> ES, then xt-comp should be unequal to
> the xt-exec (they still can be the same in some cases). Since xt-comp
> (in general case) doesn't identify CS. It's only *used* to perform CS.
>
>
> Any execution token (xt) always identifies some ES, and these ES are
> performed by applying "EXECUTE" to this xt. It's impossible that an
> execution token doesn't identify some ES.
>
>
> In the same time, some ES can be equivalent (possibly in some
> conditions) to the CS for some word, or to the IS for some word [2]. In
> such case, by performing these ES (possibly in those conditions) you
> perform the corresponding CS or IS.

Yes this is true for IF, ELSE etc in my system

>
> If the CS are (unconditionally) equivalent to the ES for some word
> "foo", then the phrase:
> [ xt-comp(foo) EXECUTE ]
> is equivalent to the phrase:
> [ ' foo EXECUTE ]
> that is equivalent to the phrase:
> foo
> in compilation state, where "xt-comp(foo)" returns xt-comp for the word
> "foo" in the considered system implementation.
>
> Hence, if for some word "foo" this phrases are not equivalent, then
> CS(foo) are not equivalent to the ES(foo). Obviously, it's a possible
> case — the case of an immediate STATE-dependent word. And in the
> considered system implementation xt-int = xt-comp in this case.
> > Would that not make dual-xt systems
> > inconsistent with the standard?
> Not in this part. But it depends.
>
> At the moment, if "NAME>COMPILE" returns xt-int(foo) and xt-int(EXECUTE)
> for an immediate STATE-dependent word "foo", then it's incorrect, I think..
>
> But the specification for "NAME>COMPILE" can be clarified to relax
> implementations. Since at the moment it controverts it's own rationale,
> when it says: "xt2 is the xt of EXECUTE (for immediate words)" [3].

As I read the standard there are no restrictions on what NAME>COMPILE
can return except that when applying EXECUTE to the returned x xt the CS
is performed.

In the rational, that you refer to, it is written:
"In a traditional xt+immediate-flag system, the x xt returned by NAME>COMPILE is typically xt1 xt2,"
the typically tells us that there can also be implementations where this is not true.
And it only applies to traditional xt+immediate flag systems, not dual-xt as discussed here.

BR
Peter

>
>
> [1] See also my proposal for FIND clarification
> https://forth-standard.org/proposals/clarify-find-more-classic-approach?hideDiff#reply-682
>
> [2] See also my reasoning concerning relations between xt, ES, CS, IS.
> https://forth-standard.org/proposals/reword-the-term-execution-token-?hideDiff#reply-570
>
> [3] https://forth-standard.org/standard/tools/NAMEtoCOMPILE
>
>
> --
> Ruvim

Re: Poll: equivalence for postpone expression

<schpt0$ci6$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=13905&group=comp.lang.forth#13905

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ruvim.pi...@gmail.com (Ruvim)
Newsgroups: comp.lang.forth
Subject: Re: Poll: equivalence for postpone expression
Date: Mon, 12 Jul 2021 19:16:30 +0300
Organization: A noiseless patient Spider
Lines: 221
Message-ID: <schpt0$ci6$1@dont-email.me>
References: <salij8$m2m$1@dont-email.me> <saptvl$jia$1@dont-email.me>
<sc4mdb$d7p$1@dont-email.me> <scc137$dqc$1@dont-email.me>
<schdj8$fdi$1@dont-email.me>
<90895d4d-2ebe-4053-8891-c33fd744307bn@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 12 Jul 2021 16:16:32 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="becabdcd09a4b21776384f49d0241dbd";
logging-data="12870"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+LDUopKZg3wNkkJtUg/bvp"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.11.0
Cancel-Lock: sha1:DV2s04MJx0SlTVh60Nc+qKWJB70=
In-Reply-To: <90895d4d-2ebe-4053-8891-c33fd744307bn@googlegroups.com>
Content-Language: en-US
 by: Ruvim - Mon, 12 Jul 2021 16:16 UTC

On 2021-07-12 16:19, P Falth wrote:
> On Monday, 12 July 2021 at 14:46:34 UTC+2, Ruvim wrote:
>> On 2021-07-10 14:42, Krishna Myneni wrote:
>>> On 7/7/21 11:57 AM, Ruvim wrote:
>>>> On 2021-06-21 14:42, Krishna Myneni wrote:
>>>>> On 6/19/21 3:03 PM, Ruvim wrote:
>>>>> ...
>>>>>>
>>>>>> Let "foo" is a word that doesn't perform any parsing, doesn't access
>>>>>> the parse area, and doesn't enter into compilation or interpretation
>>>>>> state (i.e., any such behavior is not a part of any semantics for
>>>>>> "foo").
(1)

>>>>>>
>>>>>> Let the word "compile-foo" is defined as:
>>>>>> : compile-foo postpone foo ;
>>>>>> and it has the same scope as the word "foo".
>>>>>>
>>>>>>
>>>>>>
>>>>>> Proposition 1.
>>>>>> The phrase:
>>>>>> [ compile-foo ]
>>>>>> is equivalent to the phrase:
>>>>>> foo
>>>>>> in any such context when the phrase is encountered by the Forth
>>>>>> text interpreter in compilation state.
>>>>>>
>>>>>>
>>>>>
>>>>> What is your expectation for use of the phrase "[ COMPILE-FOO ]"
>>>>> inside of a definition, when COMPILE-FOO is tagged as an immediate word?
>>>>>
>>>>> : compile-foo postpone foo ; immediate
>>>>>
>>>>> In this case the compilation semantics of COMPILE-FOO should be the
>>>>> same as its runtime semantics.
>>>>
>>>>
>>>> In the phrase "[ compile-foo ]" in compilation state, the
>>>> interpretation semantics for "compile-foo" are performed, since "["
>>>> enters interpretation state. So in this context it doesn't matter
>>>> whether "compile-foo" is immediate or not, and what its compilation
>>>> semantics.
>>>>
>>>>
>>>>
>>>> Regarding the compilation semantics for an immediate word in general.
>>>>
>>>> I assume, by "runtime semantics" you meant "execution semantics".
>>>>
>>>
>>> Yes.
>>>
>>>> In some cases, the execution semantics (ES) of an immediate word can
>>>> be nonequivalent to its compilation semantics (CS). If you make them
>>>> equivalent, you break the equivalence in P1.
>>>>
>>>> NB: Anton Ertl claimed that ES and CS should be equivalent for any
>>>> immediate word (and then P1 is false, what I consider as
>>>> inconsistency). Don't sure whether he still insist on that.
>>>>
>>>
>>> If an IMMEDIATE word does not have ES = CS, how would dual-xt systems
>>> determine the immediacy of a word?
>> First of all, a system is not obligated to determine whether a word is
>> immediate (in the standard notion) or not. It's enough to determine
>> whether a word is ordinary or not [1].
>>
>> Secondly, I don't see any technical problem with that. Various solutions
>> can be employed depending on a particular implementation. For example, a
>> separate flag can be introduced for that.
>>
>>
>>
>> As I can guess, the question is about a system where two execution
>> tokens are associated with each name token.
>>
>> One execution token (xt-int) is *used* to perform the IS for the word,
>> and another execution token (xt-comp) is *used* to perform the CS for
>> the word. If a word has default CS, then xt-comp is 0.
>
> Not necessarily. In my system a word with default CS has xt-comp=COMPILE,

Yes, it is possible too. Hence you need to compare xt-comp with xt of
"COMPILE,", instead of zero.

Anyway, this variation doesn't affect my reasoning.

>> For an immediate word xt-int and xt-comp are the same and they both are
>> equal to the xt-exec that identifies the ES for the word. And it's for
>> any immediate words. So, to determine whether a word is immediate, the
>> system compares xt-int and xt-comp.
>
> Yes this works in my system
>
>> It's wrong to assume that if CS <> ES, then xt-comp should be unequal to
>> the xt-exec (they still can be the same in some cases). Since xt-comp
>> (in general case) doesn't identify CS. It's only *used* to perform CS.
>>
>>
>> Any execution token (xt) always identifies some ES, and these ES are
>> performed by applying "EXECUTE" to this xt. It's impossible that an
>> execution token doesn't identify some ES.
>>
>>
>> In the same time, some ES can be equivalent (possibly in some
>> conditions) to the CS for some word, or to the IS for some word [2]. In
>> such case, by performing these ES (possibly in those conditions) you
>> perform the corresponding CS or IS.
>
> Yes this is true for IF, ELSE etc in my system
>
>>
>> If the CS are (unconditionally) equivalent to the ES for some word
>> "foo", then the phrase:
>> [ xt-comp(foo) EXECUTE ]
>> is equivalent to the phrase:
>> [ ' foo EXECUTE ]
>> that is equivalent to the phrase:
>> foo
>> in compilation state, where "xt-comp(foo)" returns xt-comp for the word
>> "foo" in the considered system implementation.
>>
>> Hence, if for some word "foo" this phrases are not equivalent, then
>> CS(foo) are not equivalent to the ES(foo). Obviously, it's a possible
>> case — the case of an immediate STATE-dependent word. And in the
>> considered system implementation xt-int = xt-comp in this case.
>>> Would that not make dual-xt systems
>>> inconsistent with the standard?
>> Not in this part. But it depends.
>>
>> At the moment, if "NAME>COMPILE" returns xt-int(foo) and xt-int(EXECUTE)
>> for an immediate STATE-dependent word "foo", then it's incorrect, I think.
>>
>> But the specification for "NAME>COMPILE" can be clarified to relax
>> implementations. Since at the moment it controverts it's own rationale,
>> when it says: "xt2 is the xt of EXECUTE (for immediate words)" [3].
>
> As I read the standard there are no restrictions on what NAME>COMPILE
> can return except that when applying EXECUTE to the returned x xt the CS
> is performed.
>
> In the rational, that you refer to, it is written:
> "In a traditional xt+immediate-flag system, the x xt returned by NAME>COMPILE is typically xt1 xt2,"
> the typically tells us that there can also be implementations where this is not true.
> And it only applies to traditional xt+immediate flag systems, not dual-xt as discussed here.

The problem I refer to is the same for any system implementation that
meets the mentioned conditions. Yes, "NAME>COMPILE" may return any xt at
the top. But it violates the specification *if* it returns xt of the
word and xt of "EXECUTE" for the nt of an immediate STATE-dependent
word. In the same time the rationale implies that this case meets the
specification (i.e., it's correct).

The specification says:
"Executing xt consumes x and performs the compilation semantics of
the word represented by nt".

It says nothing about any additional conditions. It means that in
compilation state the phrase:

[ "foo" find-name name>compile execute ]

should perform the CS for *any* available word "foo" that meets (1)
above. Hence, this phrase should be equivalent to the phrase:

foo

in compilation state (2).

According to the rationale, "name>compile" may return xt of the word and
xt of "EXECUTE" for an immediate word. But this equivalence is not held
*if* this immediate word is STATE-dependent.

For example, if "foo" is defined as

: foo state @ 0<> . ; immediate

and "name>compile" returns ( xt(foo) xt(execute) ) -- according to the
rationale, then the phrases above produce the different results [4].

So we have two options for "name>compile" glossary entry:

a) update the specification to relax implementations and tight
programs (specify that the returned xt should be performed in
compilation state);

b) update the rationale, remove the incorrect case, describe
implementation options for traditional xt+immediate-flag system.


Click here to read the complete article
Pages:123
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor