> Am Montag, 11. Mai 2026, 10:34:22 Mitteleuropäische Sommerzeit schrieb Bernd > Paysan: > > Am Montag, 11. Mai 2026, 05:32:51 Mitteleuropäische Sommerzeit schrieb > > > > colossus via Gforth discussion and announcements: > > > I have from time to time wanted to perform clean up actions when a marker > > > is run, often close files. Win32Forth allowed this by having MARKER-CHAIN > > > run and I found it quite useful. The other advantage of this arrangement > > > is that it is possible to localize the clean up actions in the same file > > > as the data structure is defined. > > > > > > I have attached a proposed patch. It is pretty simple and only affects the > > > marker.fs file. > > > > Maskes sense. While we have chains.fs in Gforth, we usually have a deferred > > word where you can put your chained code in. > > Looking at this concept, we should probably have two chains, one for creating > the marker, one for restoring it. A typical marker functionality comes in > pairs, like SECTION-MARKER, and SECTION-MARKER!.
Honestly, that sounds like overkill to me. I am not completely opposed to the idea. I just wanted this to be pretty simple. All I wanted here was a way for the user to add clean up actions. The usual case I find is where I have to use allocated memory or an OS resource that tends to be scarce and the reference is now beyond the value of HERE. This is really easy for the user to figure out. Yes, deferred word would work but it seems to me that a LIFO stack of clean up actions would be simpler because I don't need to know where the saved value of HERE is and it sequences the dependencies naturally since they have to be loaded first. I have always found the way Win32Forth used CHAINs had the least cognitive burden on the programmer without an insane amount of overhead. Does that make sense?
