Fw: Re: Proposed patch to marker.fs for allowing custom clean up.

> Am Montag, 11. Mai 2026, 10:34:22 Mitteleurop=C3=A4ische Sommerzeit schri=
eb Bernd=20
> Paysan:
> > Am Montag, 11. Mai 2026, 05:32:51 Mitteleurop=C3=A4ische Sommerzeit sch=
rieb
> >=20
> > colossus via Gforth discussion and announcements:
> > > I have from time to time wanted to perform clean up actions when a ma=
rker
> > > is run, often close files. Win32Forth allowed this by having MARKER-C=
HAIN
> > > run and I found it quite useful. The other advantage of this arrangem=
ent
> > > is that it is possible to localize the clean up actions in the same f=
ile
> > > as the data structure is defined.
> > >=20
> > > I have attached a proposed patch. It is pretty simple and only affect=
s the
> > > marker.fs file.
> >=20
> > Maskes sense. While we have chains.fs in Gforth, we usually have a defe=
rred
> > word where you can put your chained code in.
>=20
> Looking at this concept, we should probably have two chains, one for crea=
ting=20
> the marker, one for restoring it.  A typical marker functionality comes i=
n=20
> 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 usua=
l case I find is where I have to use allocated memory or an OS resource tha=
t tends to be scarce and the reference is now beyond the value of HERE.  Th=
is 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 v=
alue 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 ha=
d the least cognitive burden on the programmer without an insane amount of =
overhead.

Does that make sense?