Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Chemistry is applied theology. -- Augustus Stanley Owsley III


devel / comp.lang.forth / Re: Interpretation semantics of EXIT

SubjectAuthor
* Interpretation semantics of EXITnone
+* Re: Interpretation semantics of EXITAnton Ertl
|`* Re: Interpretation semantics of EXITnone
| +* Re: Interpretation semantics of EXITminf...@arcor.de
| |+- Re: Interpretation semantics of EXITdxforth
| |`* Closures without locals (was: Interpretation semantics of EXIT)Anton Ertl
| | +* Re: Closures without locals (was: Interpretation semantics of EXIT)minf...@arcor.de
| | |`- Re: Closures without locals (was: Interpretation semantics of EXIT)Anton Ertl
| | `* Re: Closures without locals (was: Interpretation semantics of EXIT)none
| |  `* Re: Closures without locals (was: Interpretation semantics of EXIT)Anton Ertl
| |   `* Re: Closures without locals (was: Interpretation semantics of EXIT)none
| |    `* Re: Closures without locals (was: Interpretation semantics of EXIT)Anton Ertl
| |     `* Re: Closures without locals (was: Interpretation semantics of EXIT)none
| |      `- Re: Closures without locals (was: Interpretation semantics of EXIT)Anton Ertl
| +* Re: Interpretation semantics of EXITAnton Ertl
| |`- Re: Interpretation semantics of EXITnone
| `* Re: Interpretation semantics of EXITluser droog
|  `* Re: Interpretation semantics of EXITdxforth
|   +* Re: Interpretation semantics of EXITnone
|   |`* Re: Interpretation semantics of EXITdxforth
|   | `* Re: Interpretation semantics of EXITHans Bezemer
|   |  `* Re: Interpretation semantics of EXITnone
|   |   `* Re: Interpretation semantics of EXITHans Bezemer
|   |    `* Re: Interpretation semantics of EXITnone
|   |     `- Re: Interpretation semantics of EXITHans Bezemer
|   `* Re: Interpretation semantics of EXITluser droog
|    `- Re: Interpretation semantics of EXITdxforth
`- Re: Interpretation semantics of EXITNN

Pages:12
Interpretation semantics of EXIT

<nnd$7b417c9f$3b0743ae@4a174ea3bfad2506>

 copy mid

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

 copy link   Newsgroups: comp.lang.forth
Newsgroups: comp.lang.forth
Subject: Interpretation semantics of EXIT
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
From: alb...@cherry (none)
Originator: albert@cherry.(none) (albert)
Message-ID: <nnd$7b417c9f$3b0743ae@4a174ea3bfad2506>
Organization: KPN B.V.
Date: Sun, 17 Apr 2022 12:57:11 +0200
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!feeder.usenetexpress.com!tr2.eu1.usenetexpress.com!94.232.112.245.MISMATCH!abe005.abavia.com!abp003.abavia.com!news.kpn.nl!not-for-mail
Lines: 44
Injection-Date: Sun, 17 Apr 2022 12:57:11 +0200
Injection-Info: news.kpn.nl; mail-complaints-to="abuse@kpn.com"
 by: none - Sun, 17 Apr 2022 10:57 UTC

Newsgroups: comp.lang.forth
Subject: Interpretation semantics for EXIT
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)

For ages now I have used the documented property of ciforth
that EXIT in interpretation mode exits INTERPRET.
A simple example would be
S" 1 2 EXIT 3 4" EVALUATE
that leaves `` 1 2 '' on the stack.
EVALUATE takes care that the original input source is
restored, and so does LOAD and INCLUDE.
I use this extensively in blocks; a block intended
for 32 bits MS-Windows is abandoned in 64 bits, or
Linux.

I am working on a lisp interpreter, inspired by
(Chuck Moore's?) BASIC interpreter. In lisp nested data
structures abound even more.
(+ 1 2 (* 2 3 4))
is a typical lisp phrase.
The basic idea is to start INTERPRET in `` ( '' with a special
CONTEXT and start a **new INSTANCE** of INTERPRET with
each next `` ( ''. However in this case you don't
save and restore the input source, but leave it as is.
Now define
' EXIT ALIAS )
and you can build a partial datastructure starting
with the corresponding `` ( '' as soon as the INTERPRET
has finished.

A more mainstream application is in REQUIRE.
A source is included and it is discovered that the facility
has already been loaded, so the remainder of the source is
discarded.
A word that abandons the current input source is long overdue,
and I'm not quite sure that EXIT is the right name.

Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

Re: Interpretation semantics of EXIT

<2022Apr18.174806@mips.complang.tuwien.ac.at>

 copy mid

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

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.lang.forth
Subject: Re: Interpretation semantics of EXIT
Date: Mon, 18 Apr 2022 15:48:06 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 63
Message-ID: <2022Apr18.174806@mips.complang.tuwien.ac.at>
References: <nnd$7b417c9f$3b0743ae@4a174ea3bfad2506>
Injection-Info: reader02.eternal-september.org; posting-host="879918baff984b89c43eb70ef59c4892";
logging-data="3966"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19FMvFzVBAmcRCyo0OFpwt4"
Cancel-Lock: sha1:oohmCgAsstZ+LDDQQ4Pm9KjhET4=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Mon, 18 Apr 2022 15:48 UTC

albert@cherry.(none) (albert) writes:
>A more mainstream application is in REQUIRE.
>A source is included and it is discovered that the facility
>has already been loaded, so the remainder of the source is
>discarded.

In Gforth we implement REQUIRE by checking first if the file has
already been loaded. IIRC the reference implementation of REQUIRED
and REQUIRE also does this. No need to discard the rest of the source
for this.

>A word that abandons the current input source is long overdue,

It seems that we have not needed such a word in Gforth, because we
don't have one. Others have such a word, so there seems to be some
need for it.

>and I'm not quite sure that EXIT is the right name.

Probably not, because EXIT has no interpretation semantics. The EXIT
and INTERPRET implementations on some systems may work to achieve the
effects you have in mind (although I doubt that it works for INCLUDED
and friends on many systems, because INCLUDED is one level out from
the processing that EVALUATE and LOAD perform).

As for the interpretation semantics of EXIT, we tried hard to give
Gforth's EXIT it's execution semantics as interpretation semantics;
this work is described in [ertl15]. However, in addition to the
complications described there, we found that we still had not covered
all the bases, requiring even more complications, so we reverted the
changes to EXIT, and in the development version EXIT is an immediate
word that *compiles* the execution semantics of EXIT when used
interpretively.

@InProceedings{ertl15,
author = {M. Anton Ertl and Bernd Paysan},
title = {From \texttt{exit} to \texttt{set-does>} --- A Story of {Gforth} Re-Implementation},
crossref = {euroforth15},
pages = {41--47},
url = {http://www.euroforth.org/ef15/papers/ertl.pdf},
url-slides = {http://www.euroforth.org/ef15/papers/ertl-slides.pdf},
OPTnote = {not refereed},
abstract = {We changed \code{exit} from an immediate to a
non-immediate word; this requires changes in the
de-allocation of locals, which leads to changes in
the implementation of colon definitions, and to
generalizing \code{does>} into \code{set-does>}
which allows the defined word to call arbitrary
execution tokens. The new implementation of locals
cleanup can usually be optimized to similar
performance as the old implementation. The new
implementation of \code{does>} has performance
similar to the old implementation, while using
\code{set-does>} results in speedups in certain
cases.}
}

- 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

Re: Interpretation semantics of EXIT

<nnd$39a2d8ad$2e895a6f@38390cf4d0e7a01a>

 copy mid

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

 copy link   Newsgroups: comp.lang.forth
Newsgroups: comp.lang.forth
References: <nnd$7b417c9f$3b0743ae@4a174ea3bfad2506> <2022Apr18.174806@mips.complang.tuwien.ac.at>
Subject: Re: Interpretation semantics of EXIT
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
From: alb...@cherry (none)
Originator: albert@cherry.(none) (albert)
Message-ID: <nnd$39a2d8ad$2e895a6f@38390cf4d0e7a01a>
Organization: KPN B.V.
Date: Tue, 19 Apr 2022 10:34:56 +0200
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!feeder.usenetexpress.com!tr3.eu1.usenetexpress.com!94.232.112.244.MISMATCH!feed.abavia.com!abe004.abavia.com!abp002.abavia.com!news.kpn.nl!not-for-mail
Lines: 101
Injection-Date: Tue, 19 Apr 2022 10:34:56 +0200
Injection-Info: news.kpn.nl; mail-complaints-to="abuse@kpn.com"
 by: none - Tue, 19 Apr 2022 08:34 UTC

In article <2022Apr18.174806@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>albert@cherry.(none) (albert) writes:
>>A more mainstream application is in REQUIRE.
>>A source is included and it is discovered that the facility
>>has already been loaded, so the remainder of the source is
>>discarded.
>
>In Gforth we implement REQUIRE by checking first if the file has
>already been loaded. IIRC the reference implementation of REQUIRED
>and REQUIRE also does this. No need to discard the rest of the source
>for this.

This is one implementation possibility. What I described is common
in c.
>
>>A word that abandons the current input source is long overdue,
>
>It seems that we have not needed such a word in Gforth, because we
>don't have one. Others have such a word, so there seems to be some
>need for it.
I hope I made the case that it is useful.
>
>>and I'm not quite sure that EXIT is the right name.
>
>Probably not, because EXIT has no interpretation semantics. The EXIT
>and INTERPRET implementations on some systems may work to achieve the
>effects you have in mind (although I doubt that it works for INCLUDED
>and friends on many systems, because INCLUDED is one level out from
>the processing that EVALUATE and LOAD perform).

A standard program according ISO can not use EXIT in interpretation
state. That is not a dogma, but a design decision.
In my implementation EXIT performs a return, i.e. pops a
continuation address for the program counter, and jumps there.
If I remove the ?EXEC (that serves to forbid EXIT in compilation
state), suddenly it performs the useful function of ending INTERPRET.
Making Forth better by removing a line, isn't that the tao of
Forth?

>
>As for the interpretation semantics of EXIT, we tried hard to give
>Gforth's EXIT it's execution semantics as interpretation semantics;
>this work is described in [ertl15]. However, in addition to the
>complications described there, we found that we still had not covered
>all the bases, requiring even more complications, so we reverted the
>changes to EXIT, and in the development version EXIT is an immediate
>word that *compiles* the execution semantics of EXIT when used
>interpretively.

I promote the case that EXIT in interpretation mode exits
INTERPRET. Much to my surprise INTERPRET is not ISO standard.
The description would be:
repeat getting words from the input and perform compilation and execution
according to STATE until the input is exhausted.
A quick check reveals that most system has it:
gforth mpeforth swiftforth.
I wonder whether it WORD and FIND could make it into the standard
and INTERPRET doesn't.
(WORD and FIND hints at implementation internal words, that
probably are not used in modern implementation.
INTERPRET OTOH is far from outdated.)

>
>@InProceedings{ertl15,
> author = {M. Anton Ertl and Bernd Paysan},
> title = {From \texttt{exit} to \texttt{set-does>} --- A Story
>of {Gforth} Re-Implementation},
> crossref = {euroforth15},
> pages = {41--47},
> url = {http://www.euroforth.org/ef15/papers/ertl.pdf},
> url-slides = {http://www.euroforth.org/ef15/papers/ertl-slides.pdf},
> OPTnote = {not refereed},
> abstract = {We changed \code{exit} from an immediate to a
> non-immediate word; this requires changes in the
> de-allocation of locals, which leads to changes in
> the implementation of colon definitions, and to
> generalizing \code{does>} into \code{set-does>}
> which allows the defined word to call arbitrary
> execution tokens. The new implementation of locals
> cleanup can usually be optimized to similar
> performance as the old implementation. The new
> implementation of \code{does>} has performance
> similar to the old implementation, while using
> \code{set-does>} results in speedups in certain
> cases.}
>}

This confirms my suspicion that LOCAL is the root of all evil ;-)

>
>- anton

Groetjes Albert

--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

Re: Interpretation semantics of EXIT

<f620bd2c-5413-447e-8c9a-18af2df1000bn@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:a05:6214:2349:b0:444:2a7b:cd5c with SMTP id hu9-20020a056214234900b004442a7bcd5cmr10924492qvb.77.1650360262137;
Tue, 19 Apr 2022 02:24:22 -0700 (PDT)
X-Received: by 2002:ad4:5b8c:0:b0:446:5ca6:bba0 with SMTP id
12-20020ad45b8c000000b004465ca6bba0mr6279378qvp.46.1650360261942; Tue, 19 Apr
2022 02:24:21 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Tue, 19 Apr 2022 02:24:21 -0700 (PDT)
In-Reply-To: <nnd$39a2d8ad$2e895a6f@38390cf4d0e7a01a>
Injection-Info: google-groups.googlegroups.com; posting-host=79.224.111.239; posting-account=AqNUYgoAAADmkK2pN-RKms8sww57W0Iw
NNTP-Posting-Host: 79.224.111.239
References: <nnd$7b417c9f$3b0743ae@4a174ea3bfad2506> <2022Apr18.174806@mips.complang.tuwien.ac.at>
<nnd$39a2d8ad$2e895a6f@38390cf4d0e7a01a>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <f620bd2c-5413-447e-8c9a-18af2df1000bn@googlegroups.com>
Subject: Re: Interpretation semantics of EXIT
From: minfo...@arcor.de (minf...@arcor.de)
Injection-Date: Tue, 19 Apr 2022 09:24:22 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 4
 by: minf...@arcor.de - Tue, 19 Apr 2022 09:24 UTC

none albert schrieb am Dienstag, 19. April 2022 um 10:34:58 UTC+2:
> This confirms my suspicion that LOCAL is the root of all evil ;-)
>

You'll love closures then. :-)

Re: Interpretation semantics of EXIT

<t3nhn8$q9h$1@gioia.aioe.org>

 copy mid

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

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!aioe.org!7AktqsUqy5CCvnKa3S0Dkw.user.46.165.242.75.POSTED!not-for-mail
From: dxfo...@gmail.com (dxforth)
Newsgroups: comp.lang.forth
Subject: Re: Interpretation semantics of EXIT
Date: Wed, 20 Apr 2022 09:47:52 +1000
Organization: Aioe.org NNTP Server
Message-ID: <t3nhn8$q9h$1@gioia.aioe.org>
References: <nnd$7b417c9f$3b0743ae@4a174ea3bfad2506>
<2022Apr18.174806@mips.complang.tuwien.ac.at>
<nnd$39a2d8ad$2e895a6f@38390cf4d0e7a01a>
<f620bd2c-5413-447e-8c9a-18af2df1000bn@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="26929"; posting-host="7AktqsUqy5CCvnKa3S0Dkw.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
X-Notice: Filtered by postfilter v. 0.9.2
Content-Language: en-GB
 by: dxforth - Tue, 19 Apr 2022 23:47 UTC

On 19/04/2022 19:24, minf...@arcor.de wrote:
> none albert schrieb am Dienstag, 19. April 2022 um 10:34:58 UTC+2:
>> This confirms my suspicion that LOCAL is the root of all evil ;-)
>>
>
> You'll love closures then. :-)

But a step too far for 200x quotations - all the disadvantages of
nameless words with little to offer in return :)

Re: Interpretation semantics of EXIT

<edb1fef9-7ae9-4b20-a83a-0195c0cd0d64n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:a0c:c788:0:b0:444:2c7f:4126 with SMTP id k8-20020a0cc788000000b004442c7f4126mr14608425qvj.50.1650453404059;
Wed, 20 Apr 2022 04:16:44 -0700 (PDT)
X-Received: by 2002:a37:9e47:0:b0:69e:a534:24b5 with SMTP id
h68-20020a379e47000000b0069ea53424b5mr7352943qke.510.1650453403861; Wed, 20
Apr 2022 04:16:43 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Wed, 20 Apr 2022 04:16:43 -0700 (PDT)
In-Reply-To: <nnd$7b417c9f$3b0743ae@4a174ea3bfad2506>
Injection-Info: google-groups.googlegroups.com; posting-host=92.40.172.14; posting-account=9A5f7goAAAD_QfJPZnlK3Xq_UhzYjdP-
NNTP-Posting-Host: 92.40.172.14
References: <nnd$7b417c9f$3b0743ae@4a174ea3bfad2506>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <edb1fef9-7ae9-4b20-a83a-0195c0cd0d64n@googlegroups.com>
Subject: Re: Interpretation semantics of EXIT
From: november...@gmail.com (NN)
Injection-Date: Wed, 20 Apr 2022 11:16:44 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 45
 by: NN - Wed, 20 Apr 2022 11:16 UTC

On Sunday, 17 April 2022 at 11:57:14 UTC+1, none albert wrote:
> Newsgroups: comp.lang.forth
> Subject: Interpretation semantics for EXIT
> X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
>
> For ages now I have used the documented property of ciforth
> that EXIT in interpretation mode exits INTERPRET.
> A simple example would be
> S" 1 2 EXIT 3 4" EVALUATE
> that leaves `` 1 2 '' on the stack.
> EVALUATE takes care that the original input source is
> restored, and so does LOAD and INCLUDE.
> I use this extensively in blocks; a block intended
> for 32 bits MS-Windows is abandoned in 64 bits, or
> Linux.
>
> I am working on a lisp interpreter, inspired by
> (Chuck Moore's?) BASIC interpreter. In lisp nested data
> structures abound even more.
> (+ 1 2 (* 2 3 4))
> is a typical lisp phrase.
> The basic idea is to start INTERPRET in `` ( '' with a special
> CONTEXT and start a **new INSTANCE** of INTERPRET with
> each next `` ( ''. However in this case you don't
> save and restore the input source, but leave it as is.
> Now define
> ' EXIT ALIAS )
> and you can build a partial datastructure starting
> with the corresponding `` ( '' as soon as the INTERPRET
> has finished.
>
> A more mainstream application is in REQUIRE.
> A source is included and it is discovered that the facility
> has already been loaded, so the remainder of the source is
> discarded.
> A word that abandons the current input source is long overdue,
> and I'm not quite sure that EXIT is the right name.
>
> Groetjes Albert
> --
> "in our communism country Viet Nam, people are forced to be
> alive and in the western country like US, people are free to
> die from Covid 19 lol" duc ha
> albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

How about calling it BAIL ?

Re: Interpretation semantics of EXIT

<2022Apr20.134942@mips.complang.tuwien.ac.at>

 copy mid

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

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.lang.forth
Subject: Re: Interpretation semantics of EXIT
Date: Wed, 20 Apr 2022 11:49:42 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 104
Message-ID: <2022Apr20.134942@mips.complang.tuwien.ac.at>
References: <nnd$7b417c9f$3b0743ae@4a174ea3bfad2506> <2022Apr18.174806@mips.complang.tuwien.ac.at> <nnd$39a2d8ad$2e895a6f@38390cf4d0e7a01a>
Injection-Info: reader02.eternal-september.org; posting-host="d7445588bf2ad18723a93ecc78c2337e";
logging-data="25048"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+MHgzclqrSWk0d72uutfjr"
Cancel-Lock: sha1:onHqzvioiWHxAm3+fLYhTU99fwo=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Wed, 20 Apr 2022 11:49 UTC

albert@cherry.(none) (albert) writes:
>In article <2022Apr18.174806@mips.complang.tuwien.ac.at>,
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>albert@cherry.(none) (albert) writes:
>>>A more mainstream application is in REQUIRE.
>>>A source is included and it is discovered that the facility
>>>has already been loaded, so the remainder of the source is
>>>discarded.
>>
>>In Gforth we implement REQUIRE by checking first if the file has
>>already been loaded. IIRC the reference implementation of REQUIRED
>>and REQUIRE also does this. No need to discard the rest of the source
>>for this.
>
>This is one implementation possibility. What I described is common
>in c.

C does not have REQUIRE and instead uses a convention of wrapping the
payload into, e.g.,

#ifndef _STDIO_H
#define _STDIO_H 1
.... payload here ...
#endif /* <stdio.h> included. */

and I guess that's what you mean. Despite this convention, C does not
have a way to prematurely end the processing of a file.

In any case, in Forth we have REQUIRED/REQUIRE, so even less need for
such a feature.

>I hope I made the case that it is useful.

You wrote that you find it useful. That does not tell us why anyone
else would find it useful.

>A standard program according ISO can not use EXIT in interpretation
>state.

No. A standard program cannot use the interpretation semantics of
EXIT.

>That is not a dogma, but a design decision.
>In my implementation EXIT performs a return, i.e. pops a
>continuation address for the program counter, and jumps there.
>If I remove the ?EXEC (that serves to forbid EXIT in compilation
>state), suddenly it performs the useful function of ending INTERPRET.
>Making Forth better by removing a line, isn't that the tao of
>Forth?

It's certainly a good idea to remove ?EXEC from EXIT, which would make
your system fail on the following standard code:

: macro1 exit ; immediate
: foo macro1 ;

Better get rid of ?EXEC and ?COMP everywhere. They only check STATE
at the time when the containing words are performed, which is not
appropriate for checking whether the interpretation semantics or the
compilation semantics of a word are performed.

It's fascinating that you used ?EXEC for EXIT. My guess is that this
happened the following way: You saw that EXIT has no interpretation
semantics, so you put in ?COMP. Of course this failed, probably on
the first exection of EXIT. So the ?COMP was obviously wrong. As a
remedy you thought you would put in ?EXEC, and it seemed to work (you
have no immediate words containing EXIT), so you left it in, but it's
just as wrong as ?COMP.

As for having EXIT with interpretation semantics, that's something we
wanted to support, as detailed in the grandparent posting. It's
certainly a good idea to add useful functionality beyond the standard,
but in the benefit was not worth the cost.

>I promote the case that EXIT in interpretation mode exits
>INTERPRET. Much to my surprise INTERPRET is not ISO standard.
>The description would be:
>repeat getting words from the input and perform compilation and execution
>according to STATE until the input is exhausted.
>A quick check reveals that most system has it:
>gforth mpeforth swiftforth.
>I wonder whether it WORD and FIND could make it into the standard
>and INTERPRET doesn't.
>(WORD and FIND hints at implementation internal words, that
>probably are not used in modern implementation.
>INTERPRET OTOH is far from outdated.)

My guess is that WORD and FIND are in Forth-94 because there were no
replacements for them in the standard at the time. For Forth-2012,
there was no replacement for FIND, and WORD is designed to work with
FIND. If you want to propose to make WORD and FIND obsolescent, now
the chances are better, because there is FIND-NAME.

As for INTERPRET, if you want it standardized, make a proposal. You
may want to provide some usage statistics to support your case.

- 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

Closures without locals (was: Interpretation semantics of EXIT)

<2022Apr20.172442@mips.complang.tuwien.ac.at>

 copy mid

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

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.lang.forth
Subject: Closures without locals (was: Interpretation semantics of EXIT)
Date: Wed, 20 Apr 2022 15:24:42 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 39
Message-ID: <2022Apr20.172442@mips.complang.tuwien.ac.at>
References: <nnd$7b417c9f$3b0743ae@4a174ea3bfad2506> <2022Apr18.174806@mips.complang.tuwien.ac.at> <nnd$39a2d8ad$2e895a6f@38390cf4d0e7a01a> <f620bd2c-5413-447e-8c9a-18af2df1000bn@googlegroups.com>
Injection-Info: reader02.eternal-september.org; posting-host="d7445588bf2ad18723a93ecc78c2337e";
logging-data="6279"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18VoTzlk6yOtzyRCN9eEpmn"
Cancel-Lock: sha1:Q2i9+Y7wfl5/GTfdnY+oh4UZFxU=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Wed, 20 Apr 2022 15:24 UTC

"minf...@arcor.de" <minforth@arcor.de> writes:
>none albert schrieb am Dienstag, 19. April 2022 um 10:34:58 UTC+2:
>> This confirms my suspicion that LOCAL is the root of all evil ;-)
>>
>
>You'll love closures then. :-)

Gforth now also has closures that don't involve locals. E.g., you can
define +FIELD and FCONSTANT as:

: +field ( n "name" -- )
[n:d + ;] alias ;

5 +field x
7 x . \ prints 12

What's happening here is that when +FIELD is running, the closure
consumes one data stack item (n); this is used to build a closure,
with the needed space allocated in the dictionary. The xt of the
closure is left on the stack, and the ALIAS creates a word X with that
xt as its execution semantics. When X is run, n (i.e., 5) is pushed
on the stack, and the "+" adds it to the 7.

So the closure mechanism transfers one data stack item from closure
creation time to closure execution time (and transferring data from
closure creation time to closure execution time is the functional
essence of closures, no locals needed for that). We also have
variants for one double ("[d:d") and one float ("[f:d"), and for
allocating the closure on the locals stack ("[n:l") and on the heap
("[n:h"), and all nine combinations. We don't have variants for more
stack items; you can use the closures that involve locals if you need
that.

- 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

Re: Closures without locals (was: Interpretation semantics of EXIT)

<c65cd706-bbdc-4b40-952f-1c63405b938bn@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:a05:620a:2683:b0:69c:8c9c:5f80 with SMTP id c3-20020a05620a268300b0069c8c9c5f80mr13610169qkp.367.1650474879160;
Wed, 20 Apr 2022 10:14:39 -0700 (PDT)
X-Received: by 2002:aed:3148:0:b0:2ed:55a5:7a92 with SMTP id
66-20020aed3148000000b002ed55a57a92mr14554213qtg.104.1650474879030; Wed, 20
Apr 2022 10:14:39 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Wed, 20 Apr 2022 10:14:38 -0700 (PDT)
In-Reply-To: <2022Apr20.172442@mips.complang.tuwien.ac.at>
Injection-Info: google-groups.googlegroups.com; posting-host=79.224.111.239; posting-account=AqNUYgoAAADmkK2pN-RKms8sww57W0Iw
NNTP-Posting-Host: 79.224.111.239
References: <nnd$7b417c9f$3b0743ae@4a174ea3bfad2506> <2022Apr18.174806@mips.complang.tuwien.ac.at>
<nnd$39a2d8ad$2e895a6f@38390cf4d0e7a01a> <f620bd2c-5413-447e-8c9a-18af2df1000bn@googlegroups.com>
<2022Apr20.172442@mips.complang.tuwien.ac.at>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <c65cd706-bbdc-4b40-952f-1c63405b938bn@googlegroups.com>
Subject: Re: Closures without locals (was: Interpretation semantics of EXIT)
From: minfo...@arcor.de (minf...@arcor.de)
Injection-Date: Wed, 20 Apr 2022 17:14:39 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 42
 by: minf...@arcor.de - Wed, 20 Apr 2022 17:14 UTC

Anton Ertl schrieb am Mittwoch, 20. April 2022 um 17:51:10 UTC+2:
> "minf...@arcor.de" <minf...@arcor.de> writes:
> >none albert schrieb am Dienstag, 19. April 2022 um 10:34:58 UTC+2:
> >> This confirms my suspicion that LOCAL is the root of all evil ;-)
> >>
> >
> >You'll love closures then. :-)
> Gforth now also has closures that don't involve locals. E.g., you can
> define +FIELD and FCONSTANT as:
>
> : +field ( n "name" -- )
> [n:d + ;] alias ;
>
> 5 +field x
> 7 x . \ prints 12
>
> What's happening here is that when +FIELD is running, the closure
> consumes one data stack item (n); this is used to build a closure,
> with the needed space allocated in the dictionary. The xt of the
> closure is left on the stack, and the ALIAS creates a word X with that
> xt as its execution semantics. When X is run, n (i.e., 5) is pushed
> on the stack, and the "+" adds it to the 7.
>
> So the closure mechanism transfers one data stack item from closure
> creation time to closure execution time (and transferring data from
> closure creation time to closure execution time is the functional
> essence of closures, no locals needed for that). We also have
> variants for one double ("[d:d") and one float ("[f:d"), and for
> allocating the closure on the locals stack ("[n:l") and on the heap
> ("[n:h"), and all nine combinations. We don't have variants for more
> stack items; you can use the closures that involve locals if you need
> that.

Thanks for that gforth example. IIUC it puts the burden of "lexical scoping"
on programmer's shoulders. But anyhow: it works, well done.

Second big step would be do this with named locals i.e. put the burden on
compiler's shoulders and let programmers enjoy more readable code. But
that's way beyond the standard, and every Forth system would take (and
have to take) a different implementation route.

Nevertheless I doubt that verbose functional programming makes much
sense in Forth's niche.

Re: Closures without locals (was: Interpretation semantics of EXIT)

<nnd$0572d880$66f81f48@3c158df8581dcc52>

 copy mid

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

 copy link   Newsgroups: comp.lang.forth
Newsgroups: comp.lang.forth
Subject: Re: Closures without locals (was: Interpretation semantics of EXIT)
References: <nnd$7b417c9f$3b0743ae@4a174ea3bfad2506> <nnd$39a2d8ad$2e895a6f@38390cf4d0e7a01a> <f620bd2c-5413-447e-8c9a-18af2df1000bn@googlegroups.com> <2022Apr20.172442@mips.complang.tuwien.ac.at>
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
From: alb...@cherry (none)
Originator: albert@cherry.(none) (albert)
Message-ID: <nnd$0572d880$66f81f48@3c158df8581dcc52>
Organization: KPN B.V.
Date: Thu, 21 Apr 2022 09:57:29 +0200
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!feed.abavia.com!abe004.abavia.com!abp001.abavia.com!news.kpn.nl!not-for-mail
Lines: 52
Injection-Date: Thu, 21 Apr 2022 09:57:29 +0200
Injection-Info: news.kpn.nl; mail-complaints-to="abuse@kpn.com"
X-Received-Bytes: 2764
 by: none - Thu, 21 Apr 2022 07:57 UTC

In article <2022Apr20.172442@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>"minf...@arcor.de" <minforth@arcor.de> writes:
>>none albert schrieb am Dienstag, 19. April 2022 um 10:34:58 UTC+2:
>>> This confirms my suspicion that LOCAL is the root of all evil ;-)
>>>
>>
>>You'll love closures then. :-)
>
>Gforth now also has closures that don't involve locals. E.g., you can
>define +FIELD and FCONSTANT as:
>
>: +field ( n "name" -- )
> [n:d + ;] alias ;
>
>5 +field x
>7 x . \ prints 12
>
>What's happening here is that when +FIELD is running, the closure
>consumes one data stack item (n); this is used to build a closure,
>with the needed space allocated in the dictionary. The xt of the
>closure is left on the stack, and the ALIAS creates a word X with that
>xt as its execution semantics. When X is run, n (i.e., 5) is pushed
>on the stack, and the "+" adds it to the 7.
>
>So the closure mechanism transfers one data stack item from closure
>creation time to closure execution time (and transferring data from
>closure creation time to closure execution time is the functional
>essence of closures, no locals needed for that). We also have
>variants for one double ("[d:d") and one float ("[f:d"), and for
>allocating the closure on the locals stack ("[n:l") and on the heap
>("[n:h"), and all nine combinations. We don't have variants for more
>stack items; you can use the closures that involve locals if you need
>that.

So it is similar to
: CONSTANT , DOES> @ ;
or defined by a class/oo mechanism :
_ class CONSTANT M: @ M; , endclass

What then is de big deal?

>
>- anton

--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

Re: Interpretation semantics of EXIT

<6f61eb73-c6ab-4a0f-91bb-776869ca0a42n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:a37:9ed7:0:b0:69e:a6bf:cc37 with SMTP id h206-20020a379ed7000000b0069ea6bfcc37mr5496292qke.744.1650720150166;
Sat, 23 Apr 2022 06:22:30 -0700 (PDT)
X-Received: by 2002:a0c:8051:0:b0:42d:ef02:183c with SMTP id
75-20020a0c8051000000b0042def02183cmr7165500qva.28.1650720149977; Sat, 23 Apr
2022 06:22:29 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Sat, 23 Apr 2022 06:22:29 -0700 (PDT)
In-Reply-To: <nnd$39a2d8ad$2e895a6f@38390cf4d0e7a01a>
Injection-Info: google-groups.googlegroups.com; posting-host=24.207.213.87; posting-account=G1KGwgkAAAAyw4z0LxHH0fja6wAbo7Cz
NNTP-Posting-Host: 24.207.213.87
References: <nnd$7b417c9f$3b0743ae@4a174ea3bfad2506> <2022Apr18.174806@mips.complang.tuwien.ac.at>
<nnd$39a2d8ad$2e895a6f@38390cf4d0e7a01a>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <6f61eb73-c6ab-4a0f-91bb-776869ca0a42n@googlegroups.com>
Subject: Re: Interpretation semantics of EXIT
From: luser.dr...@gmail.com (luser droog)
Injection-Date: Sat, 23 Apr 2022 13:22:30 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 18
 by: luser droog - Sat, 23 Apr 2022 13:22 UTC

On Tuesday, April 19, 2022 at 3:34:58 AM UTC-5, none albert wrote:
> In article <2022Apr1...@mips.complang.tuwien.ac.at>,
> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> >Probably not, because EXIT has no interpretation semantics. The EXIT
> >and INTERPRET implementations on some systems may work to achieve the
> >effects you have in mind (although I doubt that it works for INCLUDED
> >and friends on many systems, because INCLUDED is one level out from
> >the processing that EVALUATE and LOAD perform).
> A standard program according ISO can not use EXIT in interpretation
> state. That is not a dogma, but a design decision.
> In my implementation EXIT performs a return, i.e. pops a
> continuation address for the program counter, and jumps there.
> If I remove the ?EXEC (that serves to forbid EXIT in compilation
> state), suddenly it performs the useful function of ending INTERPRET.
> Making Forth better by removing a line, isn't that the tao of
> Forth?
> >

[Applause.]

Re: Closures without locals (was: Interpretation semantics of EXIT)

<2022Apr23.180820@mips.complang.tuwien.ac.at>

 copy mid

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

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.lang.forth
Subject: Re: Closures without locals (was: Interpretation semantics of EXIT)
Date: Sat, 23 Apr 2022 16:08:20 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 199
Message-ID: <2022Apr23.180820@mips.complang.tuwien.ac.at>
References: <nnd$7b417c9f$3b0743ae@4a174ea3bfad2506> <2022Apr18.174806@mips.complang.tuwien.ac.at> <nnd$39a2d8ad$2e895a6f@38390cf4d0e7a01a> <f620bd2c-5413-447e-8c9a-18af2df1000bn@googlegroups.com> <2022Apr20.172442@mips.complang.tuwien.ac.at> <c65cd706-bbdc-4b40-952f-1c63405b938bn@googlegroups.com>
Injection-Info: reader02.eternal-september.org; posting-host="72c7c14e6f293add73aaca09fa28ebe8";
logging-data="25091"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18joQGBD89drctqjNxiD7mc"
Cancel-Lock: sha1:bU3quyWCZcseej+qh0yAgb1KXs4=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Sat, 23 Apr 2022 16:08 UTC

"minf...@arcor.de" <minforth@arcor.de> writes:
>Anton Ertl schrieb am Mittwoch, 20. April 2022 um 17:51:10 UTC+2:
>> "minf...@arcor.de" <minf...@arcor.de> writes:
>> >none albert schrieb am Dienstag, 19. April 2022 um 10:34:58 UTC+2:
>> >> This confirms my suspicion that LOCAL is the root of all evil ;-)
>> >>
>> >
>> >You'll love closures then. :-)
>> Gforth now also has closures that don't involve locals. E.g., you can
>> define +FIELD and FCONSTANT as:
>>
>> : +field ( n "name" -- )
>> [n:d + ;] alias ;
>>
>> 5 +field x
>> 7 x . \ prints 12
>>
>> What's happening here is that when +FIELD is running, the closure
>> consumes one data stack item (n); this is used to build a closure,
>> with the needed space allocated in the dictionary. The xt of the
>> closure is left on the stack, and the ALIAS creates a word X with that
>> xt as its execution semantics. When X is run, n (i.e., 5) is pushed
>> on the stack, and the "+" adds it to the 7.
>>
>> So the closure mechanism transfers one data stack item from closure
>> creation time to closure execution time (and transferring data from
>> closure creation time to closure execution time is the functional
>> essence of closures, no locals needed for that). We also have
>> variants for one double ("[d:d") and one float ("[f:d"), and for
>> allocating the closure on the locals stack ("[n:l") and on the heap
>> ("[n:h"), and all nine combinations. We don't have variants for more
>> stack items; you can use the closures that involve locals if you need
>> that.
>
>Thanks for that gforth example. IIUC it puts the burden of "lexical scoping"
>on programmer's shoulders.

That's one way to see it. But does the programmer want "lexical
scoping", or something else, with lexical scoping just being the Algol
60 and Scheme way to provide it?

In 2018 I wrote up a draft of a paper on closures for Forth, and I
started with lexical scoping. This might look as follows for the
example above:

: +field ( n "name" -- )
{: n :} [: n + ;] alias ;

To make it easier to implement I required explicitly listing the
locals at the start of the closure that are referenced inside the
closure, and passing the allocation word:

: +field ( n "name" -- )
{: n :}
['] alloth <[{: : n :} n + ;] alias ;

Interestingly, the example I gave in the draft is even longer; I don't
remember what the ":" after the <[{: is intended for. With the
allocation being part of the closure start word and without the extra
":", it could look as follows:

: +field ( n "name" -- )
{: n :} d[{: n :} n + ;] alias ;

Bernd Paysan had the idea to make the implementation even simpler by
passing the data to the closure on the stack, resulting in the syntax
in the published paper (but again, the examples in the paper are more
complex):

: +field ( n "name" -- )
[{: n :}d n + ;] alias ;

This new idea required me to rewrite most of the paper
[ertl&paysan18], in particular, the examples. One thing I noticed is
that many of the examples became simpler (sometimes even simpler than
lexical scoping without the additional requirement), because I no
longer had to put the value into a local in order to pass it to the
closure. I could just leave it on the stack, and inside the closure
it would be a local. This shows IMO that what we want as programmers
is not lexical scoping, but a way to pass data to the closure.

In my EuroForth talk I then outlined that it can be done in a
pure-stack way, without locals. This was intended to be mainly food
for thought, but some time later Bernd Paysan told me that he found
that useful for passing single values, and that he had implemented it,
so one could now write

: +field ( n "name" -- )
[n:d + ;] alias ;

In this case the code is shorter, and once you know what [N:D means, I
think it's easier to understand. For passing multiple values to the
closure, this tends to become cumbersome, so for that you still have
to use the version with locals.

But of course, purists might prefer passing multiple values from the
stack(s) at closure-creation time to closure run-time. That is
certainly possible, and shows that what programmers do with closures
in most cases does not require lexical scoping.

Of course, one might say that those who practice point-free functional
programming have shown that long ago, but that's a different approach.

>Second big step would be do this with named locals i.e. put the burden on
>compiler's shoulders and let programmers enjoy more readable code.

As outlined above, Gforth has had that before it had [N:D, but it's
not lexical scoping.

Last year I wrote a paper [ertl21] about transplanting the ideas I
learned here to an Algol-family language (C).

@InProceedings{ertl&paysan18,
author = {M. Anton Ertl and Bernd Paysan},
title = {Closures --- the {Forth} way},
crossref = {euroforth18},
pages = {17--30},
url = {http://www.complang.tuwien.ac.at/papers/ertl%26paysan.pdf},
url2 = {http://www.euroforth.org/ef18/papers/ertl.pdf},
slides-url = {http://www.euroforth.org/ef18/papers/ertl-slides.pdf},
video = {https://wiki.forth-ev.de/doku.php/events:ef2018:closures},
OPTnote = {refereed},
abstract = {In Forth 200x, a quotation cannot access a local
defined outside it, and therefore cannot be
parameterized in the definition that produces its
execution token. We present Forth closures; they
lift this restriction with minimal implementation
complexity. They are based on passing parameters on
the stack when producing the execution token. The
programmer has to explicitly manage the memory of
the closure. We show a number of usage examples.
We also present the current implementation, which
takes 109~source lines of code (including some extra
features). The programmer can mechanically convert
lexical scoping (accessing a local defined outside)
into code using our closures, by applying assignment
conversion and flat-closure conversion. The result
can do everything one expects from closures,
including passing Knuth's man-or-boy test and living
beyond the end of their enclosing definitions.}
}

@Proceedings{euroforth18,
title = {34th EuroForth Conference},
booktitle = {34th EuroForth Conference},
year = {2018},
key = {EuroForth'18},
url = {http://www.euroforth.org/ef18/papers/proceedings.pdf}
}

@InProceedings{ertl21-kps,
author = {M. Anton Ertl},
crossref = {kps21},
title = {The Essence of Closures---A language design
perspective},
year = {2021},
pages = {26--33},
url = {http://www.complang.tuwien.ac.at/papers/ertl21-kps.pdf},
url-slides = {http://www.complang.tuwien.ac.at/papers/ertl21-kps-slides.pdf},
abstract = {Closures are originally associated with lexically
scoped name binding. However, in the course of
implementing closures in Gforth, it turned out that
the actual function (the essence) of closures is to
communicate data between closure creation and the
closure execution (with the closure call usually
being far from the closure creation). This paper
presents a simple language extension for C:
two-stage parameter passing, implemented with flat
closures; the first stage creates a closure, the
second stage calls it. Nested functions and access
to outer locals are not needed.}
}

@Misc{kps21,
author = {{KPS 2021}},
editor = {Hanus, Michael
and Prott, Kai-Oliver
and von Hanxleden, Reinhard
and Domr{\"o}s, S{\"o}ren},
title = {Tagungsband zum 21. Kolloquium Programmiersprachen und Grundlagen der Programmierung},
booktitle = {Tagungsband zum 21. Kolloquium Programmiersprachen und Grundlagen der Programmierung},
year = {2021},
publisher = {Self-Publishing of Department of Computer Science, Kiel},
address = {Kiel},
volume = {2021/7},
issn = {2194-6639},
doi = {10.21941/kcss/2021/7},
url = {https://macau.uni-kiel.de/receive/macau_mods_00002282},
url2 = {https://doi.org/10.21941/kcss/2021/7},
file = {:https://macau.uni-kiel.de/servlets/MCRFileNodeServlet/macau_derivate_00003380/kcss_2021_07.pdf:PDF},
language = {en}
}


Click here to read the complete article
Re: Closures without locals (was: Interpretation semantics of EXIT)

<2022Apr23.191637@mips.complang.tuwien.ac.at>

 copy mid

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

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.lang.forth
Subject: Re: Closures without locals (was: Interpretation semantics of EXIT)
Date: Sat, 23 Apr 2022 17:16:37 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 81
Message-ID: <2022Apr23.191637@mips.complang.tuwien.ac.at>
References: <nnd$7b417c9f$3b0743ae@4a174ea3bfad2506> <nnd$39a2d8ad$2e895a6f@38390cf4d0e7a01a> <f620bd2c-5413-447e-8c9a-18af2df1000bn@googlegroups.com> <2022Apr20.172442@mips.complang.tuwien.ac.at> <nnd$0572d880$66f81f48@3c158df8581dcc52>
Injection-Info: reader02.eternal-september.org; posting-host="72c7c14e6f293add73aaca09fa28ebe8";
logging-data="6660"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18N2iynwAkTD2WO8wsNyJY2"
Cancel-Lock: sha1:XIxh5eJFrlnMQTjZh+8q/t1W4HA=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Sat, 23 Apr 2022 17:16 UTC

albert@cherry.(none) (albert) writes:
>>Gforth now also has closures that don't involve locals. E.g., you can
>>define +FIELD and FCONSTANT as:
>>
>>: +field ( n "name" -- )
>> [n:d + ;] alias ;
>>
>>5 +field x
>>7 x . \ prints 12
>>
>>What's happening here is that when +FIELD is running, the closure
>>consumes one data stack item (n); this is used to build a closure,
>>with the needed space allocated in the dictionary. The xt of the
>>closure is left on the stack, and the ALIAS creates a word X with that
>>xt as its execution semantics. When X is run, n (i.e., 5) is pushed
>>on the stack, and the "+" adds it to the 7.
>>
>>So the closure mechanism transfers one data stack item from closure
>>creation time to closure execution time (and transferring data from
>>closure creation time to closure execution time is the functional
>>essence of closures, no locals needed for that). We also have
>>variants for one double ("[d:d") and one float ("[f:d"), and for
>>allocating the closure on the locals stack ("[n:l") and on the heap
>>("[n:h"), and all nine combinations. We don't have variants for more
>>stack items; you can use the closures that involve locals if you need
>>that.
>
>So it is similar to
>: CONSTANT , DOES> @ ;
>or defined by a class/oo mechanism :
>_ class CONSTANT M: @ M; , endclass
>
>What then is de big deal?

Yes, I selected an example that Forth programmers may be more familiar
with than the numeric integration example that I used more heavily in
the paper and that has led to complaints that people unfamiliar with
numerical integration cannot follow the example.

So yes, you can implement this +FIELD with DOES>:

: +field ( n "name" -- )
create ,
does> @ + ;

(BTW, the stack effect of all +FIELD examples I gave in this thread is
non-standard, but that should not detract from the point of the
example (at least nobody has complained about it yet).

Here are some differences between closures and CREATE...DOES>:

* A closure is nameless (so the code above uses ALIAS to give it a
name); there is no standard way to make a nameless CREATEd word.

* A closure can be allocated in the dictionary (as done here), on the
heap, on the locals stack, or using a user-supplied allocation word.
With CREEATE..DOES>, you are limited to dictionary allocation (and
its lifetime).

* [N:D takes a cell off the stack at closre creation time, and pushes
it on closure execution time, without the programmer having to
manage the data in between (other than supplying an allocation
method). With CREATE..DOES>, the programmer has to store the data
to the dictionary with "," and get it from there with @.

* [N:D can manage the data in any way it sees fit, and the programmer
knows very little about that. As a result, the data is immutable
for the program, so the closure could be inlined, and the data could
be compiled as a literal (with a very sophisticated compiler). By
contrast, the user can change the data of a CREATE-+FIELD child with
>BODY, so even a very sophisticated implementation has to compile a
fetch of that data.

Whether you consider these differences a big deal, is up to you.

- 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

Re: Interpretation semantics of EXIT

<t428i6$16k9$1@gioia.aioe.org>

 copy mid

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

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!aioe.org!7AktqsUqy5CCvnKa3S0Dkw.user.46.165.242.75.POSTED!not-for-mail
From: dxfo...@gmail.com (dxforth)
Newsgroups: comp.lang.forth
Subject: Re: Interpretation semantics of EXIT
Date: Sun, 24 Apr 2022 11:19:03 +1000
Organization: Aioe.org NNTP Server
Message-ID: <t428i6$16k9$1@gioia.aioe.org>
References: <nnd$7b417c9f$3b0743ae@4a174ea3bfad2506>
<2022Apr18.174806@mips.complang.tuwien.ac.at>
<nnd$39a2d8ad$2e895a6f@38390cf4d0e7a01a>
<6f61eb73-c6ab-4a0f-91bb-776869ca0a42n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="39561"; posting-host="7AktqsUqy5CCvnKa3S0Dkw.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
X-Notice: Filtered by postfilter v. 0.9.2
Content-Language: en-GB
 by: dxforth - Sun, 24 Apr 2022 01:19 UTC

On 23/04/2022 23:22, luser droog wrote:
> On Tuesday, April 19, 2022 at 3:34:58 AM UTC-5, none albert wrote:
>> In article <2022Apr1...@mips.complang.tuwien.ac.at>,
>> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>> >Probably not, because EXIT has no interpretation semantics. The EXIT
>> >and INTERPRET implementations on some systems may work to achieve the
>> >effects you have in mind (although I doubt that it works for INCLUDED
>> >and friends on many systems, because INCLUDED is one level out from
>> >the processing that EVALUATE and LOAD perform).
>> A standard program according ISO can not use EXIT in interpretation
>> state. That is not a dogma, but a design decision.
>> In my implementation EXIT performs a return, i.e. pops a
>> continuation address for the program counter, and jumps there.
>> If I remove the ?EXEC (that serves to forbid EXIT in compilation
>> state), suddenly it performs the useful function of ending INTERPRET.
>> Making Forth better by removing a line, isn't that the tao of
>> Forth?
>> >
>
> [Applause.]

Except ANSForth isn't Forth. It's a federation (or confederation if one
believes it was a choice) of Forth implementers. EXIT in interpret state
is one of the many things it couldn't get agreement upon. Mistaking
ANSForth for a created language is what results in the 'I could have done
it better' complaints. Well yes, almost anyone could have created a better
Forth but that's not what was being offered.

Re: Closures without locals (was: Interpretation semantics of EXIT)

<nnd$0789d801$67988155@a613019019771a7c>

 copy mid

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

 copy link   Newsgroups: comp.lang.forth
Newsgroups: comp.lang.forth
References: <nnd$7b417c9f$3b0743ae@4a174ea3bfad2506> <2022Apr20.172442@mips.complang.tuwien.ac.at> <nnd$0572d880$66f81f48@3c158df8581dcc52> <2022Apr23.191637@mips.complang.tuwien.ac.at>
Subject: Re: Closures without locals (was: Interpretation semantics of EXIT)
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
From: alb...@cherry (none)
Originator: albert@cherry.(none) (albert)
Message-ID: <nnd$0789d801$67988155@a613019019771a7c>
Organization: KPN B.V.
Date: Sun, 24 Apr 2022 10:34:05 +0200
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.uzoreto.com!feeder.usenetexpress.com!tr1.eu1.usenetexpress.com!94.232.112.246.MISMATCH!abe006.abavia.com!abp003.abavia.com!news.kpn.nl!not-for-mail
Lines: 135
Injection-Date: Sun, 24 Apr 2022 10:34:05 +0200
Injection-Info: news.kpn.nl; mail-complaints-to="abuse@kpn.com"
 by: none - Sun, 24 Apr 2022 08:34 UTC

In article <2022Apr23.191637@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>albert@cherry.(none) (albert) writes:
>>>Gforth now also has closures that don't involve locals. E.g., you can
>>>define +FIELD and FCONSTANT as:
>>>
>>>: +field ( n "name" -- )
>>> [n:d + ;] alias ;
>>>
>>>5 +field x
>>>7 x . \ prints 12
>>>
>>>What's happening here is that when +FIELD is running, the closure
>>>consumes one data stack item (n); this is used to build a closure,
>>>with the needed space allocated in the dictionary. The xt of the
>>>closure is left on the stack, and the ALIAS creates a word X with that
>>>xt as its execution semantics. When X is run, n (i.e., 5) is pushed
>>>on the stack, and the "+" adds it to the 7.
>>>
>>>So the closure mechanism transfers one data stack item from closure
>>>creation time to closure execution time (and transferring data from
>>>closure creation time to closure execution time is the functional
>>>essence of closures, no locals needed for that). We also have
>>>variants for one double ("[d:d") and one float ("[f:d"), and for
>>>allocating the closure on the locals stack ("[n:l") and on the heap
>>>("[n:h"), and all nine combinations. We don't have variants for more
>>>stack items; you can use the closures that involve locals if you need
>>>that.
>>
>>So it is similar to
>>: CONSTANT , DOES> @ ;
>>or defined by a class/oo mechanism :
>>_ class CONSTANT M: @ M; , endclass
>>
>>What then is de big deal?
>
>Yes, I selected an example that Forth programmers may be more familiar
>with than the numeric integration example that I used more heavily in
>the paper and that has led to complaints that people unfamiliar with
>numerical integration cannot follow the example.
>
>So yes, you can implement this +FIELD with DOES>:
>
>: +field ( n "name" -- )
> create ,
>does> @ + ;
>
>(BTW, the stack effect of all +FIELD examples I gave in this thread is
>non-standard, but that should not detract from the point of the
>example (at least nobody has complained about it yet).
>
>Here are some differences between closures and CREATE...DOES>:
>
>* A closure is nameless (so the code above uses ALIAS to give it a
> name); there is no standard way to make a nameless CREATEd word.

If you allow me to use the alternative oo-ish definition of constant
`` _ class CONSTANT M: get @ M; , endclass ''
gives me also a BUILD-CONSTANT that does exactly that,

>
>* A closure can be allocated in the dictionary (as done here), on the
> heap, on the locals stack, or using a user-supplied allocation word.
> With CREEATE..DOES>, you are limited to dictionary allocation (and
> its lifetime).

I prefer to separate those interests. As soon as it is important
to allocate objects to a heap -- and it is, occasionally -- I'm inclined
to add an extra word to an allocate wordset

13 \ Make a freshly created object at `HERE permanent. (o -- o )
14 : >ALLOC DUP >R HERE OVER - DUP ALLOCATE THROW
15 DUP >R SWAP MOVE R> R> DP ! ;

If you wish you can redefine BUILD-CONSTANT :
: BUILD-CONSTANT BUILD-CONSTANT >ALLOC ;

>
>* [N:D takes a cell off the stack at closre creation time, and pushes
> it on closure execution time, without the programmer having to
> manage the data in between (other than supplying an allocation
> method). With CREATE..DOES>, the programmer has to store the data
> to the dictionary with "," and get it from there with @.

I agree that one CREATE..DOES> gets you only so far, so it is
good to think further.

>
>* [N:D can manage the data in any way it sees fit, and the programmer
> knows very little about that. As a result, the data is immutable
> for the program, so the closure could be inlined, and the data could
> be compiled as a literal (with a very sophisticated compiler). By
> contrast, the user can change the data of a CREATE-+FIELD child with
> >BODY, so even a very sophisticated implementation has to compile a
> fetch of that data.

The idea of objects is that you guide the way the user is to
handle CONSTANTS as above . In general I have not supplied
a method a user can change the constant, so that is similar.
`` _ class CONSTANT M: get @ M; , endclass ''

So the class definition of CONSTANTS is superior to using
CREATE in much the same way in this respect.
(Except for getting through a heavy-handed use of a `this' pointer
that is similar to use of >BODY ).

Rules that an optimiser can follow, are in this context maybe
simpler. I don't believe in the complicated things a compiler
can do if she is allowed to assume that the e.g. a c-program does
nothing "undefined". (As do you apparently.)
Early FORTRAN's had the rule that if a variable was identified
in two different ways (aliasing), optimisation wasn't allowed, and
that the programmer has to take care. Those Spartan
attitudes in regard to optimisation is more the Forth way.
I guess that closures introduced in Forth would require a lot
of caveats, that is not worth it, and cramps the Forth way,
as in IMHO the use of LOCAL values, and global VALUEs.

>
>Whether you consider these differences a big deal, is up to you.

For the moment I will prefer simple additions to Forth to
achieve similar goals. I'm working on an optimiser and that
may change my opinion.

>
>- anton

Groetjes.
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

Re: Interpretation semantics of EXIT

<nnd$1d028f0d$6fd346f6@a613019019771a7c>

 copy mid

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

 copy link   Newsgroups: comp.lang.forth
Newsgroups: comp.lang.forth
References: <nnd$7b417c9f$3b0743ae@4a174ea3bfad2506> <nnd$39a2d8ad$2e895a6f@38390cf4d0e7a01a> <6f61eb73-c6ab-4a0f-91bb-776869ca0a42n@googlegroups.com> <t428i6$16k9$1@gioia.aioe.org>
Subject: Re: Interpretation semantics of EXIT
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
From: alb...@cherry (none)
Originator: albert@cherry.(none) (albert)
Message-ID: <nnd$1d028f0d$6fd346f6@a613019019771a7c>
Organization: KPN B.V.
Date: Sun, 24 Apr 2022 10:39:05 +0200
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!193.141.40.65.MISMATCH!npeer.as286.net!npeer-ng0.as286.net!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!feed.abavia.com!abe004.abavia.com!abp003.abavia.com!news.kpn.nl!not-for-mail
Lines: 41
Injection-Date: Sun, 24 Apr 2022 10:39:05 +0200
Injection-Info: news.kpn.nl; mail-complaints-to="abuse@kpn.com"
X-Received-Bytes: 2867
 by: none - Sun, 24 Apr 2022 08:39 UTC

In article <t428i6$16k9$1@gioia.aioe.org>, dxforth <dxforth@gmail.com> wrote:
>On 23/04/2022 23:22, luser droog wrote:
>> On Tuesday, April 19, 2022 at 3:34:58 AM UTC-5, none albert wrote:
>>> In article <2022Apr1...@mips.complang.tuwien.ac.at>,
>>> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>>> >Probably not, because EXIT has no interpretation semantics. The EXIT
>>> >and INTERPRET implementations on some systems may work to achieve the
>>> >effects you have in mind (although I doubt that it works for INCLUDED
>>> >and friends on many systems, because INCLUDED is one level out from
>>> >the processing that EVALUATE and LOAD perform).
>>> A standard program according ISO can not use EXIT in interpretation
>>> state. That is not a dogma, but a design decision.
>>> In my implementation EXIT performs a return, i.e. pops a
>>> continuation address for the program counter, and jumps there.
>>> If I remove the ?EXEC (that serves to forbid EXIT in compilation
>>> state), suddenly it performs the useful function of ending INTERPRET.
>>> Making Forth better by removing a line, isn't that the tao of
>>> Forth?
>>> >
>>
>> [Applause.]
>
>Except ANSForth isn't Forth. It's a federation (or confederation if one
>believes it was a choice) of Forth implementers. EXIT in interpret state
>is one of the many things it couldn't get agreement upon. Mistaking
>ANSForth for a created language is what results in the 'I could have done
>it better' complaints. Well yes, almost anyone could have created a better
>Forth but that's not what was being offered.

You could not accuse me of not embracing ANSForth. Proposals in this way
serve as incremental improvements of Forth.
Considering ANSForth as dogma, was that something Jeff Fox and Chuck Moore
warned about?

Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

Re: Closures without locals (was: Interpretation semantics of EXIT)

<2022Apr24.182147@mips.complang.tuwien.ac.at>

 copy mid

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

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.lang.forth
Subject: Re: Closures without locals (was: Interpretation semantics of EXIT)
Date: Sun, 24 Apr 2022 16:21:47 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 113
Message-ID: <2022Apr24.182147@mips.complang.tuwien.ac.at>
References: <nnd$7b417c9f$3b0743ae@4a174ea3bfad2506> <2022Apr20.172442@mips.complang.tuwien.ac.at> <nnd$0572d880$66f81f48@3c158df8581dcc52> <2022Apr23.191637@mips.complang.tuwien.ac.at> <nnd$0789d801$67988155@a613019019771a7c>
Injection-Info: reader02.eternal-september.org; posting-host="7808d2ba18980fcd7c5c8cae83d7a0dd";
logging-data="15182"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/ngPeyyT1iQfb4ukX5TaLv"
Cancel-Lock: sha1:IW0qC5feStmVKYbx77MB6Y5HKBc=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Sun, 24 Apr 2022 16:21 UTC

albert@cherry.(none) (albert) writes:
>In article <2022Apr23.191637@mips.complang.tuwien.ac.at>,
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>Here are some differences between closures and CREATE...DOES>:
>>
>>* A closure is nameless (so the code above uses ALIAS to give it a
>> name); there is no standard way to make a nameless CREATEd word.
>
>If you allow me to use the alternative oo-ish definition of constant
>`` _ class CONSTANT M: get @ M; , endclass ''
>gives me also a BUILD-CONSTANT that does exactly that,

Sure, but then we are not into comparing Gforth's closures with
CREATE...DOES>, but comparing them with your OO extension.

>>* [N:D can manage the data in any way it sees fit, and the programmer
>> knows very little about that. As a result, the data is immutable
>> for the program, so the closure could be inlined, and the data could
>> be compiled as a literal (with a very sophisticated compiler). By
>> contrast, the user can change the data of a CREATE-+FIELD child with
>> >BODY, so even a very sophisticated implementation has to compile a
>> fetch of that data.
....
>Rules that an optimiser can follow, are in this context maybe
>simpler. I don't believe in the complicated things a compiler
>can do if she is allowed to assume that the e.g. a c-program does
>nothing "undefined". (As do you apparently.)

It's unclear what you think that I do apparently, but you can find my
position on undefined behaviour in C in
<http://www.complang.tuwien.ac.at/papers/ertl17kps.pdf>

Concerning Forth, I think we should eliminate many ambiguous
conditions or at least define them in the implementations. But I
think that, e.g., it is not a valuable feature to be able to change
constants in the way that is possible in classic threaded-code
systems:

5 constant x
: foo x ;
6 ' x >body !
x . \ 6 on gforth-0.7.9 gforth-itc-0.7.9 sf-3.11 vfxlin-4.72; crash on iforth
foo . \ 6 on gforth-itc-0.7.9; 5 on gforth-0.7.9 sf-3.11 vfxlin-4.72 iforth

Of course, if you think it if valuable to get 6 from the last line,
you can use gforth-itc or any other threaded-code system, at a certain
cost in performance: about a factor 2-3 for gforth-itc compared to
gforth-fast.

Likewise, I don't think it is a valuable feature to be able to change
the offset of +FIELD after it has been defined, so it is useful to be
able to define it in a way without that feature. If you want that
feature, you can define it with closures:

: +field ( n "name" -- )
here swap , [n:d @ + ;] alias ;

It's more cumbersome, and there is no easy way to find the cell you
would change, but if you find and change that cell, the offset will
change everywhere.

Alternatively, you can implement [N:D in your system in such a way
that you can also change the offset with the other [N:D-based
definitions of +FIELD, just like you can change constants in
gforth-itc.

Concerning the complexity of the compiler, compiling a closure into
another word efficiently is relatively simple: compile the value(s)
passed into the closure as literal(s), then compile a call to the code
inside the closure (possibly inlining the call).

E.g., if I have

: +field ( n "name" -- )
[n:d + ;] alias ;

5 +field x

: foo x @ ;

this could be compiled with relatively little effort as

\ here's a named version of the closure code:
: +field-closure1-code
+ ;

: foo 5 +field-closure1-code @ ;

Compiling that with vfxlin-4.72 gives:

see foo
FOO
( 080C0AC0 8B5B05 ) MOV EBX, [EBX+05]
( 080C0AC3 C3 ) NEXT,
( 4 bytes, 2 instructions )

>>Whether you consider these differences a big deal, is up to you.
>
>For the moment I will prefer simple additions to Forth to
>achieve similar goals.

Implementing [N:D and friends is pretty simple. Currently closures.fs
has 227 lines (including comment lines and empty lines), but includes
a lot of extra functionality.

How big are your simple additions?

- 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

Re: Closures without locals (was: Interpretation semantics of EXIT)

<nnd$62ab0458$15663ab9@b51c4c9ef67e13a3>

 copy mid

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

 copy link   Newsgroups: comp.lang.forth
Newsgroups: comp.lang.forth
References: <nnd$7b417c9f$3b0743ae@4a174ea3bfad2506> <2022Apr23.191637@mips.complang.tuwien.ac.at> <nnd$0789d801$67988155@a613019019771a7c> <2022Apr24.182147@mips.complang.tuwien.ac.at>
Subject: Re: Closures without locals (was: Interpretation semantics of EXIT)
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
From: alb...@cherry (none)
Originator: albert@cherry.(none) (albert)
Message-ID: <nnd$62ab0458$15663ab9@b51c4c9ef67e13a3>
Organization: KPN B.V.
Date: Sun, 24 Apr 2022 21:07:14 +0200
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!abe006.abavia.com!abp003.abavia.com!news.kpn.nl!not-for-mail
Lines: 55
Injection-Date: Sun, 24 Apr 2022 21:07:14 +0200
Injection-Info: news.kpn.nl; mail-complaints-to="abuse@kpn.com"
X-Received-Bytes: 2516
 by: none - Sun, 24 Apr 2022 19:07 UTC

In article <2022Apr24.182147@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
<SNIP>
>
>Implementing [N:D and friends is pretty simple. Currently closures.fs
>has 227 lines (including comment lines and empty lines), but includes
>a lot of extra functionality.
>
>How big are your simple additions?

ALLOCATE : 3 screens ( >ALLOC sneaked in)
class : 1 screen
FORMAT&EVAL : 1 screen (needed for class)
SWAP-DP : 1 screen (scratch compilation area)
Likewise they contain functionality besides implementing
defective pseudo-closures.

These are compacted source library items. The originals were developed
using files. Reckon some 30 lines for source files per block,
maybe more if REGRESS (test lines) are present.

To have an idea of code I use woc (words of code),
the count doesn't differ between file source and block source.
The woc-count is 615 in total. The loc-count is not saying much
depending how generous one is regarding blank lines, or
the presence of the GPL2 copyright in full.
The woc count is also not sensitive to a horizontal or
vertical layout.

----------------------
#!/bin/sh

cat $1 |\
sed -e 's/\\ .*//' |\
sed -e 's/( [^)]*)//g' |\
sed -e '/\<DOC\>/,/\<ENDDOC\>/d'|\
sed -e 's/\\D .*//' |\
wc -w

exit
----------------------

>
>- anton
>--
>M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html

Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

Re: Interpretation semantics of EXIT

<nnd$76824edd$51cd50eb@542c27e8767ff9d3>

 copy mid

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

 copy link   Newsgroups: comp.lang.forth
Newsgroups: comp.lang.forth
References: <nnd$7b417c9f$3b0743ae@4a174ea3bfad2506> <2022Apr18.174806@mips.complang.tuwien.ac.at> <nnd$39a2d8ad$2e895a6f@38390cf4d0e7a01a> <2022Apr20.134942@mips.complang.tuwien.ac.at>
Subject: Re: Interpretation semantics of EXIT
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
From: alb...@cherry (none)
Originator: albert@cherry.(none) (albert)
Message-ID: <nnd$76824edd$51cd50eb@542c27e8767ff9d3>
Organization: KPN B.V.
Date: Sun, 24 Apr 2022 22:06:06 +0200
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!abe005.abavia.com!abp002.abavia.com!news.kpn.nl!not-for-mail
Lines: 57
Injection-Date: Sun, 24 Apr 2022 22:06:06 +0200
Injection-Info: news.kpn.nl; mail-complaints-to="abuse@kpn.com"
X-Received-Bytes: 3266
 by: none - Sun, 24 Apr 2022 20:06 UTC

In article <2022Apr20.134942@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>albert@cherry.(none) (albert) writes:
<SNIP>
>Better get rid of ?EXEC and ?COMP everywhere. They only check STATE
>at the time when the containing words are performed, which is not
>appropriate for checking whether the interpretation semantics or the
>compilation semantics of a word are performed.
>
>It's fascinating that you used ?EXEC for EXIT. My guess is that this
>happened the following way: You saw that EXIT has no interpretation
>semantics, so you put in ?COMP. Of course this failed, probably on
>the first exection of EXIT. So the ?COMP was obviously wrong. As a
>remedy you thought you would put in ?EXEC, and it seemed to work (you
>have no immediate words containing EXIT), so you left it in, but it's
>just as wrong as ?COMP.

I introduced ?EXEC in my story to get a point across.
I don't actually use ?EXEC. If you look at my example of INTERPRET,
you would realize that I don't check compilation mode in EXIT.
In my implementation EXIT is a code word that pops the high level
interpreter pointer from the return stack, then goes next.
It is rigorously equivalent to the return instruction native
code forth's use.

?EXEC is available as a loadable extension if you want to go traditional:
65( -traditional- ?LOADING ?EXEC TRIAD ABORT" ) \ AvdH C2feb22

>
>As for having EXIT with interpretation semantics, that's something we
>wanted to support, as detailed in the grandparent posting. It's
>certainly a good idea to add useful functionality beyond the standard,
>but in the benefit was not worth the cost.

Good to hear that.

>
>As for INTERPRET, if you want it standardized, make a proposal. You
>may want to provide some usage statistics to support your case.

INTERPRET blends in in the ciforth model. It is not trivial to
made it fit to ISO, as this is not a model, and a lot of details
can go wrong. I will reflect upon the matter.
If you build a Forth from scratch, you are forced to implement WORD
with special case BL WORD, but you may not want use that internally. I
don't want to add another such word.

>
>- anton
>--
Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

Re: Interpretation semantics of EXIT

<t450ai$q1l$1@gioia.aioe.org>

 copy mid

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

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!aioe.org!7AktqsUqy5CCvnKa3S0Dkw.user.46.165.242.75.POSTED!not-for-mail
From: dxfo...@gmail.com (dxforth)
Newsgroups: comp.lang.forth
Subject: Re: Interpretation semantics of EXIT
Date: Mon, 25 Apr 2022 12:16:51 +1000
Organization: Aioe.org NNTP Server
Message-ID: <t450ai$q1l$1@gioia.aioe.org>
References: <nnd$7b417c9f$3b0743ae@4a174ea3bfad2506>
<nnd$39a2d8ad$2e895a6f@38390cf4d0e7a01a>
<6f61eb73-c6ab-4a0f-91bb-776869ca0a42n@googlegroups.com>
<t428i6$16k9$1@gioia.aioe.org> <nnd$1d028f0d$6fd346f6@a613019019771a7c>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="26677"; posting-host="7AktqsUqy5CCvnKa3S0Dkw.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
X-Notice: Filtered by postfilter v. 0.9.2
Content-Language: en-GB
 by: dxforth - Mon, 25 Apr 2022 02:16 UTC

On 24/04/2022 18:39, albert wrote:
> In article <t428i6$16k9$1@gioia.aioe.org>, dxforth <dxforth@gmail.com> wrote:
>>On 23/04/2022 23:22, luser droog wrote:
>>> On Tuesday, April 19, 2022 at 3:34:58 AM UTC-5, none albert wrote:
>>>> In article <2022Apr1...@mips.complang.tuwien.ac.at>,
>>>> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>>>> >Probably not, because EXIT has no interpretation semantics. The EXIT
>>>> >and INTERPRET implementations on some systems may work to achieve the
>>>> >effects you have in mind (although I doubt that it works for INCLUDED
>>>> >and friends on many systems, because INCLUDED is one level out from
>>>> >the processing that EVALUATE and LOAD perform).
>>>> A standard program according ISO can not use EXIT in interpretation
>>>> state. That is not a dogma, but a design decision.
>>>> In my implementation EXIT performs a return, i.e. pops a
>>>> continuation address for the program counter, and jumps there.
>>>> If I remove the ?EXEC (that serves to forbid EXIT in compilation
>>>> state), suddenly it performs the useful function of ending INTERPRET.
>>>> Making Forth better by removing a line, isn't that the tao of
>>>> Forth?
>>>> >
>>>
>>> [Applause.]
>>
>>Except ANSForth isn't Forth. It's a federation (or confederation if one
>>believes it was a choice) of Forth implementers. EXIT in interpret state
>>is one of the many things it couldn't get agreement upon. Mistaking
>>ANSForth for a created language is what results in the 'I could have done
>>it better' complaints. Well yes, almost anyone could have created a better
>>Forth but that's not what was being offered.
>
> You could not accuse me of not embracing ANSForth. Proposals in this way
> serve as incremental improvements of Forth.
> Considering ANSForth as dogma, was that something Jeff Fox and Chuck Moore
> warned about?
>
> Groetjes Albert

EXIT was a regular word in Forth-79/83 until someone decided they could
'improve' on it.

Re: Closures without locals (was: Interpretation semantics of EXIT)

<2022Apr25.075626@mips.complang.tuwien.ac.at>

 copy mid

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

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.lang.forth
Subject: Re: Closures without locals (was: Interpretation semantics of EXIT)
Date: Mon, 25 Apr 2022 05:56:26 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 40
Message-ID: <2022Apr25.075626@mips.complang.tuwien.ac.at>
References: <nnd$7b417c9f$3b0743ae@4a174ea3bfad2506> <2022Apr23.191637@mips.complang.tuwien.ac.at> <nnd$0789d801$67988155@a613019019771a7c> <2022Apr24.182147@mips.complang.tuwien.ac.at> <nnd$62ab0458$15663ab9@b51c4c9ef67e13a3>
Injection-Info: reader02.eternal-september.org; posting-host="fa898341b02b22b9cb86425dd70c2a5d";
logging-data="11308"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+qma/XFfM3ipDkDND+F5zb"
Cancel-Lock: sha1:1nVgYBt7btC62CEZolzYr+7sXps=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Mon, 25 Apr 2022 05:56 UTC

albert@cherry.(none) (albert) writes:
>To have an idea of code I use woc (words of code),
>the count doesn't differ between file source and block source.
>The woc-count is 615 in total. The loc-count is not saying much
>depending how generous one is regarding blank lines, or
>the presence of the GPL2 copyright in full.
>The woc count is also not sensitive to a horizontal or
>vertical layout.
>
>----------------------
>#!/bin/sh
>
>cat $1 |\
> sed -e 's/\\ .*//' |\
> sed -e 's/( [^)]*)//g' |\
> sed -e '/\<DOC\>/,/\<ENDDOC\>/d'|\
> sed -e 's/\\D .*//' |\
> wc -w
>
>exit
>----------------------

cat closures.fs |
sed -e 's/\\ .*//' |
sed -e 's/( [^)]*)//g' |
sed -e 's/\\G .*//'|
sed -e 's/\\D .*//'|
head -209|
wc -w
622

The "head -209" is there to avoid counting the man-or-boy-test that's
there as a test (normally inactive).

- 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

Re: Interpretation semantics of EXIT

<f604da7a-a588-4761-8c54-fdc5ce5e0571n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:ac8:5789:0:b0:2f3:63d9:62e4 with SMTP id v9-20020ac85789000000b002f363d962e4mr15883492qta.382.1651120132613;
Wed, 27 Apr 2022 21:28:52 -0700 (PDT)
X-Received: by 2002:a05:6214:4108:b0:456:31ce:d5ff with SMTP id
kc8-20020a056214410800b0045631ced5ffmr15559329qvb.127.1651120132446; Wed, 27
Apr 2022 21:28:52 -0700 (PDT)
Path: i2pn2.org!rocksolid2!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Wed, 27 Apr 2022 21:28:52 -0700 (PDT)
In-Reply-To: <t428i6$16k9$1@gioia.aioe.org>
Injection-Info: google-groups.googlegroups.com; posting-host=24.207.213.87; posting-account=G1KGwgkAAAAyw4z0LxHH0fja6wAbo7Cz
NNTP-Posting-Host: 24.207.213.87
References: <nnd$7b417c9f$3b0743ae@4a174ea3bfad2506> <2022Apr18.174806@mips.complang.tuwien.ac.at>
<nnd$39a2d8ad$2e895a6f@38390cf4d0e7a01a> <6f61eb73-c6ab-4a0f-91bb-776869ca0a42n@googlegroups.com>
<t428i6$16k9$1@gioia.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <f604da7a-a588-4761-8c54-fdc5ce5e0571n@googlegroups.com>
Subject: Re: Interpretation semantics of EXIT
From: luser.dr...@gmail.com (luser droog)
Injection-Date: Thu, 28 Apr 2022 04:28:52 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 34
 by: luser droog - Thu, 28 Apr 2022 04:28 UTC

On Saturday, April 23, 2022 at 8:19:05 PM UTC-5, dxforth wrote:
> On 23/04/2022 23:22, luser droog wrote:
> > On Tuesday, April 19, 2022 at 3:34:58 AM UTC-5, none albert wrote:
> >> In article <2022Apr1...@mips.complang.tuwien.ac.at>,
> >> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> >> >Probably not, because EXIT has no interpretation semantics. The EXIT
> >> >and INTERPRET implementations on some systems may work to achieve the
> >> >effects you have in mind (although I doubt that it works for INCLUDED
> >> >and friends on many systems, because INCLUDED is one level out from
> >> >the processing that EVALUATE and LOAD perform).
> >> A standard program according ISO can not use EXIT in interpretation
> >> state. That is not a dogma, but a design decision.
> >> In my implementation EXIT performs a return, i.e. pops a
> >> continuation address for the program counter, and jumps there.
> >> If I remove the ?EXEC (that serves to forbid EXIT in compilation
> >> state), suddenly it performs the useful function of ending INTERPRET.
> >> Making Forth better by removing a line, isn't that the tao of
> >> Forth?
> >> >
> >
> > [Applause.]
> Except ANSForth isn't Forth. It's a federation (or confederation if one
> believes it was a choice) of Forth implementers. EXIT in interpret state
> is one of the many things it couldn't get agreement upon. Mistaking
> ANSForth for a created language is what results in the 'I could have done
> it better' complaints. Well yes, almost anyone could have created a better
> Forth but that's not what was being offered.

I don't know enough about the whole story to weigh in there,
just saying that Albert made a compelling point. So compelling
that the rest of the story kinda reads as just noise to me.
If I can figure out how to use it, my personal forth will do it this way.
And that's all I'm likely to use anyway.

Until I stumble across something better.

Re: Interpretation semantics of EXIT

<t4dd7v$1ohu$1@gioia.aioe.org>

 copy mid

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

 copy link   Newsgroups: comp.lang.forth
Path: i2pn2.org!i2pn.org!aioe.org!7AktqsUqy5CCvnKa3S0Dkw.user.46.165.242.75.POSTED!not-for-mail
From: dxfo...@gmail.com (dxforth)
Newsgroups: comp.lang.forth
Subject: Re: Interpretation semantics of EXIT
Date: Thu, 28 Apr 2022 16:46:23 +1000
Organization: Aioe.org NNTP Server
Message-ID: <t4dd7v$1ohu$1@gioia.aioe.org>
References: <nnd$7b417c9f$3b0743ae@4a174ea3bfad2506>
<2022Apr18.174806@mips.complang.tuwien.ac.at>
<nnd$39a2d8ad$2e895a6f@38390cf4d0e7a01a>
<6f61eb73-c6ab-4a0f-91bb-776869ca0a42n@googlegroups.com>
<t428i6$16k9$1@gioia.aioe.org>
<f604da7a-a588-4761-8c54-fdc5ce5e0571n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="57918"; posting-host="7AktqsUqy5CCvnKa3S0Dkw.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.1
X-Notice: Filtered by postfilter v. 0.9.2
Content-Language: en-GB
 by: dxforth - Thu, 28 Apr 2022 06:46 UTC

On 28/04/2022 14:28, luser droog wrote:
> On Saturday, April 23, 2022 at 8:19:05 PM UTC-5, dxforth wrote:
>> On 23/04/2022 23:22, luser droog wrote:
>> > On Tuesday, April 19, 2022 at 3:34:58 AM UTC-5, none albert wrote:
>> >> In article <2022Apr1...@mips.complang.tuwien.ac.at>,
>> >> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>> >> >Probably not, because EXIT has no interpretation semantics. The EXIT
>> >> >and INTERPRET implementations on some systems may work to achieve the
>> >> >effects you have in mind (although I doubt that it works for INCLUDED
>> >> >and friends on many systems, because INCLUDED is one level out from
>> >> >the processing that EVALUATE and LOAD perform).
>> >> A standard program according ISO can not use EXIT in interpretation
>> >> state. That is not a dogma, but a design decision.
>> >> In my implementation EXIT performs a return, i.e. pops a
>> >> continuation address for the program counter, and jumps there.
>> >> If I remove the ?EXEC (that serves to forbid EXIT in compilation
>> >> state), suddenly it performs the useful function of ending INTERPRET.
>> >> Making Forth better by removing a line, isn't that the tao of
>> >> Forth?
>> >> >
>> >
>> > [Applause.]
>> Except ANSForth isn't Forth. It's a federation (or confederation if one
>> believes it was a choice) of Forth implementers. EXIT in interpret state
>> is one of the many things it couldn't get agreement upon. Mistaking
>> ANSForth for a created language is what results in the 'I could have done
>> it better' complaints. Well yes, almost anyone could have created a better
>> Forth but that's not what was being offered.
>
> I don't know enough about the whole story to weigh in there,
> just saying that Albert made a compelling point. So compelling
> that the rest of the story kinda reads as just noise to me.
> If I can figure out how to use it, my personal forth will do it this way.
> And that's all I'm likely to use anyway.
>
> Until I stumble across something better.

For a while I had an EXIT with a ?COMP. To stop interpretation of a screen
I defined:

: \\ source >in ! drop ; immediate

For text files it was extended to:

-? : \\
tf? if
begin tfill 0= until
end postpone \\ ; immediate

When EXIT reverted to a regular word I saw little point changing them. What
was once a neat trick back in the Fig-Forth days had lost its shine.

Re: Interpretation semantics of EXIT

<ce65773c-3b15-40a3-b57b-bfcaa9d43748n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.lang.forth
X-Received: by 2002:ac8:58cc:0:b0:2f3:67ca:d466 with SMTP id u12-20020ac858cc000000b002f367cad466mr14091271qta.557.1651149970766;
Thu, 28 Apr 2022 05:46:10 -0700 (PDT)
X-Received: by 2002:a05:622a:10c:b0:2f3:528e:25d6 with SMTP id
u12-20020a05622a010c00b002f3528e25d6mr22703440qtw.209.1651149970613; Thu, 28
Apr 2022 05:46:10 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.forth
Date: Thu, 28 Apr 2022 05:46:10 -0700 (PDT)
In-Reply-To: <t450ai$q1l$1@gioia.aioe.org>
Injection-Info: google-groups.googlegroups.com; posting-host=77.174.47.232; posting-account=Ebqe4AoAAABfjCRL4ZqOHWv4jv5ZU4Cs
NNTP-Posting-Host: 77.174.47.232
References: <nnd$7b417c9f$3b0743ae@4a174ea3bfad2506> <nnd$39a2d8ad$2e895a6f@38390cf4d0e7a01a>
<6f61eb73-c6ab-4a0f-91bb-776869ca0a42n@googlegroups.com> <t428i6$16k9$1@gioia.aioe.org>
<nnd$1d028f0d$6fd346f6@a613019019771a7c> <t450ai$q1l$1@gioia.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <ce65773c-3b15-40a3-b57b-bfcaa9d43748n@googlegroups.com>
Subject: Re: Interpretation semantics of EXIT
From: the.beez...@gmail.com (Hans Bezemer)
Injection-Date: Thu, 28 Apr 2022 12:46:10 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 22
 by: Hans Bezemer - Thu, 28 Apr 2022 12:46 UTC

On Monday, April 25, 2022 at 4:16:53 AM UTC+2, dxforth wrote:
> EXIT was a regular word in Forth-79/83 until someone decided they could
> 'improve' on it.

I agree. In 4tH, having Forth-79 roots, EXIT is still a very simple word: get TORS,
put it in the instruction pointer and continue (Ok, some checks are made - agreed).

It's not that much different from a RET instruction in Z80 - and why should it? It's
just there as a counterpart for a CALL.

Of course, if you add several other services (like taking care of locals) it will most
probably become a bit beefier. That's one of the reasons why I don't like locals in
the first place.

Of course I love them in C - but C is not Forth.

And those who have a history with my ramblings here won't be too surprised to
hear that I don't like over-complicated Forths, which absolutely improve in "ease of
use", but IMHO lose this "simple elegance" quality of Forth I fell in love with.

So dxforth, I concur with you on this point.

Hans Bezemer

Re: Interpretation semantics of EXIT

<nnd$7009dbae$66cd4e3c@74c551b4634c4c38>

 copy mid

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

 copy link   Newsgroups: comp.lang.forth
Newsgroups: comp.lang.forth
References: <nnd$7b417c9f$3b0743ae@4a174ea3bfad2506> <nnd$1d028f0d$6fd346f6@a613019019771a7c> <t450ai$q1l$1@gioia.aioe.org> <ce65773c-3b15-40a3-b57b-bfcaa9d43748n@googlegroups.com>
Subject: Re: Interpretation semantics of EXIT
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
From: alb...@cherry (none)
Originator: albert@cherry.(none) (albert)
Message-ID: <nnd$7009dbae$66cd4e3c@74c551b4634c4c38>
Organization: KPN B.V.
Date: Thu, 28 Apr 2022 15:13:52 +0200
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!feed.abavia.com!abe004.abavia.com!abp003.abavia.com!news.kpn.nl!not-for-mail
Lines: 55
Injection-Date: Thu, 28 Apr 2022 15:13:52 +0200
Injection-Info: news.kpn.nl; mail-complaints-to="abuse@kpn.com"
X-Received-Bytes: 2738
 by: none - Thu, 28 Apr 2022 13:13 UTC

In article <ce65773c-3b15-40a3-b57b-bfcaa9d43748n@googlegroups.com>,
Hans Bezemer <the.beez.speaks@gmail.com> wrote:
>On Monday, April 25, 2022 at 4:16:53 AM UTC+2, dxforth wrote:
>> EXIT was a regular word in Forth-79/83 until someone decided they could
>> 'improve' on it.
>
>I agree. In 4tH, having Forth-79 roots, EXIT is still a very simple
>word: get TORS,
>put it in the instruction pointer and continue (Ok, some checks are made
>- agreed).
>
>It's not that much different from a RET instruction in Z80 - and why
>should it? It's
>just there as a counterpart for a CALL.
>
>Of course, if you add several other services (like taking care of
>locals) it will most
>probably become a bit beefier. That's one of the reasons why I don't
>like locals in
>the first place.
>
>Of course I love them in C - but C is not Forth.
>
>And those who have a history with my ramblings here won't be too surprised to
>hear that I don't like over-complicated Forths, which absolutely improve
>in "ease of
>use", but IMHO lose this "simple elegance" quality of Forth I fell in love with.

Lately I became fond of AUTOLOAD
They CATCH any errors from the interpreting a line.
If the error is 12 of 10 (undefined) , the name is WANTED through the
library. If it succeeds, compilation goes on as if nothing happens.
WANT AUTOLOAD
SEE LOCATE
Neither of SEE or LOCATE is in the kernel, but it works.

Of course AUTOLOAD is a loadable extension, only available after
WANT AUTOLOAD .

>
>So dxforth, I concur with you on this point.

So do I, but it is possible to make life easier without compromising
the simplicity of the kernel Forth.

>
>Hans Bezemer

Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

Pages:12
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor