Am Dienstag, 12. Mai 2026, 11:46:02 Mitteleuropäische Sommerzeit schrieb colossus: > > 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.
With the sections system we now have in Gforth, it's not that simple anymore, because other sections can have live stuff that is above HERE. We have code that restores the DPs of other sections, but no check what got removed. > 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? The cognitive burden of adding something to MARKER, and MARKER! is like this: :is marker, ( -- ) defers marker, my-value @ , ; :is marker! ( addr1 -- addr2 ) defers marker! @+ my-value ! ; That's it. Maybe we can make it even easier by providing :chain <defered word> that does the defers as first step, too. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o id: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* https://net2o.de/
signature.asc
Description: This is a digitally signed message part.
