Sujet : Re: Back & Forth - Co-routines
De : anton (at) *nospam* mips.complang.tuwien.ac.at (Anton Ertl)
Groupes : comp.lang.forthDate : 10. Feb 2025, 00:08:22
Autres entêtes
Organisation : Institut fuer Computersprachen, Technische Universitaet Wien
Message-ID : <2025Feb10.000822@mips.complang.tuwien.ac.at>
References : 1 2 3 4 5 6 7 8 9 10 11
User-Agent : xrn 10.11
Paul Rubin <
no.email@nospam.invalid> writes:
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
The :}D means that the closure data is stored in the dictionary; there
is also :}L (for locals, deallocated when the surrounding definition
is exited), :}H (heap, deallocated with FREE-CLOSURE), and :}H1 (heap,
deallocated right after the first (and only) execution).
>
This is pretty cool, but it looks like quotations within the closure
aren't allowed to access the closure's locals
Correct. You need to use a closure (and perform closure conversion
and assignment conversion manually, if needed).
This is an attempt to make a counting function, like in Scheme:
>
(define (x)
((lambda (n)
(lambda ()
(set! n (+ 1 n))
n)) 0))
>
(define a (x))
>
(a) ; 1
(a) ; 2, etc.
: x ( -- xt )
here 0 , [{: addr :}d addr @ 1+ dup addr ! ;] ;
x alias a
x alias b
a . \ 1
a . \ 2
b . \ 1
a . \ 3
Given that you are using dictionary allocation, traditional Forth
allocation for the mutable data is fine. There is also a syntax for
allocating data in other locations, but you don't need it with
dictionary allocation and traditional dictionary allocation is usually
shorter. With that syntax the equivalent would be:
: x ( -- xt )
0 <{: w^ n :}d n ;> drop [{: n :}d n @ 1+ dup n ! ;] ;
The other issue is that the value-flavoured local N or ADDR in the
closure cannot be changed in a way that takes effect outside the
closure. So you give an address to it, and use @, ! etc. to work on
that (assignment conversion).
It would be interesting if your conservative gc could be made reliable
and included with gforth, and then another suffix could be added to put
closure locals in the gc'd heap.
Yes. There is :}xt for passing an xt that performs the allocation.
See <
https://gforth.org/manual/Closures.html> for all of these topics.
Or read the paper:
@InProceedings{ertl&paysan18,
author = {M. Anton Ertl and Bernd Paysan},
title = {Closures --- the {Forth} way},
crossref = {euroforth18},
pages = {17--30},
url = {
https://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.}
}
Also in a threaded
program I guess it would have to stop any threads that shared a GC'd
heap during collection of that heap.
That's a tough one. My current thinking is along the lines of a
per-thread allocator and garbage-collector, with no heap-allocated
data passed between threads. Then thread-unaware GCs are good enough.
- anton
-- M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.htmlcomp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html New standard: https://forth-standard.org/EuroForth 2023 proceedings: http://www.euroforth.org/ef23/papers/EuroForth 2024 proceedings:
http://www.euroforth.org/ef24/papers/