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

--nextPartFv6Hu8PORdOwlaxviljabg
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"; protected-headers="v1"
From: Bernd Paysan <[email protected]>
To: "gforth-mXXj517/[email protected]" <gforth-mXXj517/[email protected]>
Cc: colossus <[email protected]>
Subject: Re: Fw: Re: Proposed patch to marker.fs for allowing custom clean up.
Date: Tue, 12 May 2026 15:47:52 +0200
Message-ID: <[email protected]>
MIME-Version: 1.0

Am Dienstag, 12. Mai 2026, 11:46:02 Mitteleurop=C3=A4ische Sommerzeit schri=
eb=20
colossus:
> > Am Montag, 11. Mai 2026, 10:34:22 Mitteleurop=C3=A4ische Sommerzeit sch=
rieb
> > Bernd>=20
> > Paysan:
> > > Am Montag, 11. Mai 2026, 05:32:51 Mitteleurop=C3=A4ische Sommerzeit s=
chrieb
> > >=20
> > > 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.
> > > >=20
> > > > I have attached a proposed patch. It is pretty simple and only affe=
cts
> > > > the
> > > > marker.fs file.
> > >=20
> > > Maskes sense. While we have chains.fs in Gforth, we usually have a
> > > deferred
> > > word where you can put your chained code in.
> >=20
> > 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!.
>=20
> Honestly, that sounds like overkill to me.  I am not completely opposed to
> the idea.  I just wanted this to be pretty simple.
>=20
> All I wanted here was a way for the user to add clean up actions.  The us=
ual
> 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.  Th=
is
> is really easy for the user to figure out.

With the sections system we now have in Gforth, it's not that simple anymor=
e,=20
because other sections can have live stuff that is above HERE.  We have cod=
e=20
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 cle=
an
> 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.
>=20
> Does that make sense?

The cognitive burden of adding something to MARKER, and MARKER! is like thi=
s:

: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 wo=
rd>=20
that does the defers as first step, too.

=2D-=20
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o id: kQusJzA;7*?t=3Duy@X}1GWr!+0qqp_Cn176t4(dQ*
https://net2o.de/

--nextPartFv6Hu8PORdOwlaxviljabg
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iQJPBAABCAA5FiEERJ1NDqPQRwYnwBjr9y2Uk5MtoGcFAmoDL4gbFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMiwyAAoJEPctlJOTLaBnu98P/AgE8JpM/G+aZvgDxsqE
RfW+VC131Jl5nDKnHa+h9iqBJGhFYI1Q9SJnxhLtPb4xYNda1ULgoecWdhMTdIny
5WpakuHA4Ir8dpryxZnd7McP23E/NGrjr3moMASOgko0z7GDQkCF7f0KoqKVhI5R
Ij8SmURz3lborR5S+HuN/X2hEH9sUgLwmo835ggYJCYVE6r4b8ufxru+UvIhkNbh
ahwTYD8teRArhOwVaRCZq7Fb6opufUkVqghoyiGT+dLjCkejMwnDwsve8sDrUhZG
O/sNc6C6nvTa/qYG24dBI6cES/4Bu8ssUQwbWUGOP65bmSWGpIX6wOWwZ5QbG5MT
D06AipEf35RUpujSzDTlWTN/4ZEuVsbP5WUo8C9G0Ks5545V7nr+97pHLYoTBBn5
6MpX7nc2CScwWmcqSwHRo1eFs3Unh97ooV6k7qKlNsPbL2JIqGCx9q+bnzjTyYCw
yy5wvrS6CzYO/Xe0Q0Y94ZraeB60dXhHO4YxcT2ApZnquGz0a+FAFSZuB9qupRHt
BY8NT3ifWZ1HMWM3MTzPgnFjKI6SgoJF7SfBDwtwhY5h+onJwLVSvqx7xL6Xd44C
KvTFh9l0IdpmPXi8Cnk/jVPa4w8VZ2hC1aerBrcwqdz1bv/ckqW55f9hyT1Ewolu
XA51da2/9RmbSH3NNpmuUnYk
=PVO9
-----END PGP SIGNATURE-----

--nextPartFv6Hu8PORdOwlaxviljabg--