Deutsch English Français Italiano |
<2024Aug1.153554@mips.complang.tuwien.ac.at> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: anton@mips.complang.tuwien.ac.at (Anton Ertl) Newsgroups: comp.lang.forth Subject: Re: Operator =?UTF-8?B?b3ZlcmxvYWRpbmc/?= Date: Thu, 01 Aug 2024 13:35:54 GMT Organization: Institut fuer Computersprachen, Technische Universitaet Wien Lines: 66 Message-ID: <2024Aug1.153554@mips.complang.tuwien.ac.at> References: <a1aab44ee3b1b56c2f54f2606e98d040@www.novabbs.com> <pzvvwo76lx5kh.fsf@barkhauseninstitut.org> <698bd09c6db27738ab6a1c3222aba1e1@www.novabbs.com> <2024Jul25.140858@mips.complang.tuwien.ac.at> <a0acecd6d9e2fd8067bf19c9050b1c15@www.novabbs.com> <2024Jul27.173555@mips.complang.tuwien.ac.at> <b400d597f040f25db107a6c77c55d40a@www.novabbs.com> Injection-Date: Thu, 01 Aug 2024 15:48:26 +0200 (CEST) Injection-Info: dont-email.me; posting-host="9c6cb8df3cbe72c15b04922cd88fdb90"; logging-data="2312287"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/Qn5eT/th1qB6VVceFzYH8" Cancel-Lock: sha1:Tw4cjvsGiHa4/yzvlZQn51rnr7E= X-newsreader: xrn 10.11 Bytes: 3945 minforth@gmx.net (minforth) writes: >On Sat, 27 Jul 2024 15:35:55 +0000, Anton Ertl wrote: >> minforth@gmx.net (minforth) writes: >>>[[: ;]] define closures, but unlike gforth's more flexible >>>flat closures, they capture simply all upvalues (here local a). >> >> Gforth's flag closures can be considered lower-level (they come out of >> implementation ideas in the Scheme community) and are easier to >> implement, but emulating closures that capture outer locals is more >> cumbersome. > >In MF36 quotations already have read/write access to the locals of the >parent function. So closures became a simple by-product through >capturing >the parent's locals stack and injecting it at startup during closure >runtime. When the closure finishes, the captured stack is simply >updated. > >I don't know if this would be good enough for a Lisp/Scheme programmer, >but it works for my needs. And look Ma, no garbage collection. :-) But then, with | : INIT { a } | [[: a ;]] \ read counter | [[: 1 +to a ;]] ; \ increment counter | DEFER count IS count | DEFER read IS read | 5 INIT | COUNT COUNT READ -> should give 7 is A not gone after INIT is finished, and COUNT and READ will do ... interesting things? >> One other aspect is that in Gforth's closures the >> programmer decides whether closures are allocated in the dictionary, >> on the locals stack, on the heap, or elsewhere. > >In MF36 it is only the locals stack. AFAIU in other programming >languagues there are closures where the parent function can be seen as >constructor. IOW call the parent function twice and you get different >xts/addresses. From this perspective MF36 closures would perhaps only >qualify as 'half-closures'. Your description sounds like MF36 can do downwards funargs (like Pascal), but not upward funargs. >> This raises the question of why you want to use closures for this >> task. Why not use one of the object-oriented Forth packages, some of >> which support value-flavoured fields (Mini-OOF2 among them AFAIK). > >MF36 VALUEs and LOCALs are already built with method VTs. TO et al >just call the method in the correct method slot. Sure, but the point here is how to define an INIT that initializes some data, and then you can call COUNT and READ on it, possibly with different INITs for different types. And you don't want to give names to all the things that are produced by INIT. That sounds like a job for an object-oriented package. - 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: https://forth-standard.org/ EuroForth 2024: https://euro.theforth.net